Hackers Handbook - Millenium Edition

home *** CD-ROM | disk | FTP | other *** search

/ Hackers Handbook - Millenium Edition / Hackers Handbook.iso / library / hack / howtocrk.txt < prev next >

Wrap

Text File | 1997-09-25 | 283.1 KB | 9,217 lines

HOW TO CRACK, by +ORC, A TUTORIAL -------------------------------------------------------------- (Htocrk10.txt) Lesson 1: an approach (Htocrk20.txt) Lesson 2: tools and tricks of the trade (Htocrk31.txt) Lesson 3.1: hands on, paper protections (1) (Htocrk32.txt) Lesson 3.2: hands on, paper protections (2) (Htocrk51.txt) Lesson 5.1: disk & CD-Rom access (basics) (Htocrk61.txt) Lesson 6.1: funny tricks (Htocrk81.txt) Lesson 8.1: how to crack Windows, an approach (Htocrk82.txt) Lesson 8.2: how to crack Windows, a deeper approach (Htocrk91.txt) Lesson 9.1: how to crack Windows, hands on (Htocrka1.txt) Lesson A.1: advanced cracking: internet cracking (Unix) (Htocrkc1.txt) Lesson C.1: how to crack, cracking as an art (Htocrkc2.txt) Lesson C.2: how to crack, cracking as an art HOW TO CRACK, by +ORC, A TUTORIAL --------------------------------------------------------------------------- Lesson 1: an approach --------------------------------------------------------------------------- [Pooldemo.exe] -------------------------------------- The best way to learn cracking (i.e. understanding, broadly individuating, locating exactly and eliminating or suspending or deferring one or more protection schemes inside a software application you do not possess the source code of) is to begin your tampering experiments using OLDER applications which have OLDER protection schemes. In this way you 'll quickly grasp the base techniques of the trade. Do not forget that the evolution of the protection schemes has not been a one way road... strictly speaking it's not even an evolution: you'll eventually find some very clever new tricks, but most of the time you 'll unearth only various trite repetitions of past (and well known) tricks. This is no wonder: the REAL knowledge of the "commercial" programmers themselves (the "protectionists") is often very limited indeed: they are inclined to use the old methods (albeit somehow changed, sometimes even improved) instead of conceiving new methods. This typical "commercial" degeneration happens every time people act for money instead of doing things for the sake of it or for pleasure. This "commercial" trend is blindly encouraged by the stupid, money-oriented society we are coerced to live in. So I'll begin the "hands on" part (-> starting from lesson 3), using as examples, some "old" applications and some "old" tricks. We'll be able to come later over to the newest protection schemes in order to understand them, and you 'll learn how to defeat this kind of junk too. I'll also explain WHERE you can find a lot of programs to crack for next to no money at all, and HOW 'grossomodo', you should proceed in your work. This tutorial is for people who are getting started with cracking. Maybe you are just contemplating doing some cracking, maybe you have tried it with mixed success. If you are here to get aimed in the right direction, to get off to a good start with the cracking tricks and procedures, then you have come for the right reason. I can't promise you'll get what you want, but I'll do my best. On the other hand, if you have already turned out some working cracking code in assembler and already cracked many different protection schemes, then this tutorial is likely to be on the elementary side for you. (If you want to review a few basics and have no where else pressing to go, then by all means stay). In order to crack successfully you need four basic things: * A passing knowledge of assembler language (the more you know, the better and quicker you crack) * Some intuition * Some help from more experienced cracker * A non mercantile mind (more about this later) The applications you'll use to learn with can be divided into: 1 - Password crippled applications (the easiest to crack) 2 - applications crippled on how many times, or how many days, you use them (fairly easy to crack) 3 - applications crippled on which date you use them before (easy to crack) 4 - applications that have some functions present but disabled (sometimes easy, sometimes difficult) 5 - applications crippled on Disk access (protections schemes that are now defined as "obsolete") and applications crippled on CD-ROM presence (more or less the same methods, but - somehow- not defined as "obsolete") (very easy to crack) 6 - CRYPTOGRAFED ADDS ON (i.e. one of the previous protection schemes, but with some scrambled or self modifying code (XORring and SHRLing codes) (fairly easy to crack) 7 - None of the above (sometimes difficult to crack) WHERE TO GET THE STUFF The recent widespread appearance of "Demo"-CDROM on magazine covers is a treasure for all crackers! A short time after their release you 'll get all the copies that remain unsold for next to free. The demos on CD-ROMs will permit you to gather quickly a lot of applications -old and new- that have somehow been crippled (at times with interesting schemes). Truly a wonderful world of cracking possibilities! Gee! For next to no money you can secure on one CDROM the whole of LOTUS applications (or Microsoft or Wordperfect, or you name them) on "trial for 30 days" or "try it 20 times" editions. You'll really enjoy to crack them, to use them for ever and ever and/or graciously donate them on the Web to the poor lamers that have no money and no brain. GAMES are definitely not to be frowned upon! They are very interesting from a cracker prospective coz they are often "overprotected". With this I mean that they possess protection schemes of a relatively HIGH level hidden inside files that are relatively small. Now, see, it is much more easy, and simple, to track down and eliminate protection schemes inside a single 35.000 bytes long executable file than to locate them inside a collection of many lengthy DLLs and overlaids that could have swollen as long as 2.000.000 bytes each. The lazy bunch of "modern" programmers relies systematically for protection schemes on this "hide the sting in the wide desert" logic. As a matter of fact they are no longer able to program in assembler: they bank more and more on overbloated "fatty" atrocities like Visual Basic, Delphy or Visual C++. (Don't worry... I'll nevertheless teach you how to crack -and quickly- those huge applications too). There is another reason for employing games instead of applications as study material: often EXACTLY THE SAME protection schemes that you find in a simple (and short) shareware game will be used -without much improving- a little later in order to "protect" some huge and extremely expensive graphic application. For this reason in my tutorial we'll often crack games protection schemes, even if we'll later apply what we learn mainly in order to crack the protection schemes of commercial applications, or to crack the access protection routines to remote servers, or BBS, or even ATM (cash dispensers). Here follows an example cracking session, that will show you -I hope- the dos and donts of our art: let's crack together as introductory example a time crippled application. We'll learn later (-> LESSON 4) that all applications that are crippled on time (i.e. "how many times" you use them or "how long" you use them) rely on analogous protection schemes (albeit with a huge palette of small variations): 1- they may have a counter which "clicks" every so often: FIND IT AND DISABLE IT! 2- they may fetch the time_clock interrupts in your machine: INTERCEPT THEM YOURSELF! 3- they may compare a random_seed with a variable: NOOP IT! 4- they may check randomly the date of your other, unrelated, files on the hard disk: find this verification routine and INVERT the JUMPS! I wanted to start with a modern example of this "counter clicks" protection type, just to give you a feeling for cracking, and I have chosen a widely published demo: you should be able to find it pretty easily. In order to show you some of the problems you may encounter we'll crack this example "wrongly" (you'll learn how to crack effectively in the "HANDS ON" lessons). EXAMPLE: ARCADE POOL, Demonstration version, PC Conversion by East Point Software Ltd, (c) Team 17 Software Ltd 1994. This demo has been published by many magazines on their CDRom covers throughout 1995. What follows will be useful even if you do not have our example; nevertheless you should get a copy of this widespread demo in order to better grasp some of the following points. This nice demo of a billiard game is time-crippled. It is crippled on how long you use it: i.e., you can only play 2 minutes, afterwards a "nag" reminder of where and how you can buy the real version snaps: protectionist squalor at its best. So, how do you proceed? Where does the beginning begin? Here is what you could (but not necessarily should) do: Get [Soft-ice] and load it in your config.sys. See the TOOLS OF THE TRADE lesson (-> LESSON 2) about this debugger. Version 2.6 of [Soft-Ice] has been cracked by MARQUIS DE SOIREE and can be found on the Web for free. - vecs s (save all the vectors before loading the babe) - start [pooldemo.exe] - vecs c (vector compare, save a printing of all hooked vectors) - enter and leave Soft-ice a few times to understand what's going on and where in [pooldemo.exe] are we roaming around (you should always check MORE THAN ONCE your findings when you snoop around: nothing moves and confuses pointers in a more frenzied way than good old "inactive" DOS). - have a good look at the map of memory usage ("map") - now "snap_save" the main memory regions where [pooldemo.exe] dwells... snapping saves "photographs" of memory areas. - do not do anything, let just the seconds go by. - "snap_compare" every two or three seconds without moving anything at all on the game board (no mouse_clicking, NOTHING), so that the only changes are (hopefully) the changes caused by the time counters. - snap_compare twice in a second. - snap_compare at second 00:59 and at second 1:01. - snap_compare just before and just after the time limit and the snapping of the nag screen. - Now collect carefully your printed "snaps" data: write clearly on the various sheets the occurrences of the snaps. - now comes the graceful "zen-cracking" moment: Sit down with a dry Martini and Wodka (obviously only russian Wodka will do) and contemplate the printing of the various mutant locations. Feel, perceive, empathize! Look closely at the locations that have changed in the snap compares. Analyze, interpretate, evaluate. - Mmm! Hey! Something fishy is changing there, and there, and there! (you are lucky, few do actually change in this case: only two dozen) - breakpoint on execute at the location that you believe act as a "continuous" counter, i.e. the location that triggers the "a second went by" event when it zeroes. - Now set the occurrence counter of BPX in order to break at the moment where the location "refills" and restarts from the beginning (the equivalent of "one second" went by, let's start anew). Use the occurrence counter in order not to single-step through the program your life long! - IN THIS CASE you 'll quickly locate the refill at location 3DD0. Here follows the "refill" line: xxxx:3DCC C706F1013C00 MOV WORD PTR [01F1], 003C The "3C" byte at xxxx:3DD0 represents a counter_byte... i.e. the program "charges" 3C in this location and then DECs it step by step to 3B, 3A, 39, 38 etc... till 0. When it reaches 0: bingo! Sucker user has lost one second more of his precious two minutes. Now, you would get a first wizard level if you searched further on for the exact point where you get the "nag screen" in order to eliminate the whole witless protection, but you may think you got it already and you remember anyway that the first principle in cracking is the following: "once you can eliminate the effects of a protection, do not look further!" Most of the time this is true: you do not always need to eliminate a "whole" protection scheme (unless you are just studying it for the joy of it). It's normally easier (and quicker) to eliminate the "effects" of a given protection scheme. Unfortunately this is not true in this case. Here you believe that you have already found the way: you got the counter that charges the reverse clock that triggers the particular protection scheme of [pooldemo.exe]. Now you may think that if you could modify the refill_value... say changing "3C" to "EE" (Yeah, the maximum would be FF... but it's always good practice to avoid such extreme values when cracking) you should get four times more playtime for your game... more than enough in order to make the protection scheme useless. So you change location xxxx:3DD0 from "3C" to "EE". To work on bytes you should use a good Hexeditor like PSEDIT (Parity solutions, [Psedit.exe], brilliant shareware: see the "tool of the trade" section) but you could also work with simpler debuggers like [debug] or [symdeb] (-> see lesson 2). If you do, remember to work on a "dead" copy of your crippled [*.exe] file, i.e.: ren POOLDEMO.EXE POOLDEMO.DED symdeb POOLDEMO.DED -s (cs+0000):0 Lffff C7 06 F1 01 C3 <- this string corresponds to the refill line). cs:3E85 <- symdeb gives you two locations as answer cs:3EEA -e cs:3E85+4 EE <- refill changed from C3 to EE -w ren POOLDEMO.DED POOLDEMO.EXE Now you run your tampered pooldemo. You think you cracked it, you glee with satisfaction... but loo! Nothing at all has changed, everything's as lame as before, you still have only 2 minutes playtime. How disappointing: how comez it didn't work? Well, for a start you have not been attentive enough! The search in debug gave you TWO locations, you moron, and not just the one you just tampered with. Check and you 'll see that the second location (cs:3EEA) is a MIRROR/CONTROL location (more on this later). Some times there exist "double" locations... coz at times it's quicker to use a double routine than to use a branching if or switch structure... some times the second locations do mirror the first ones and correct them on the fly if need be. So you need to modify this too... you act as said above but this time you enter in debug a -e cs:3EEA+4 EE before writing back the dead file and then renaming it to exe and then running it... and loo! Hoow sloow! THERE YOU ARE! Your crippled POOLDEMO.EXE is now (sort of) unprotected: You think that you can now play the stupid game up to 12 minutes real time, even if the protection scheme (and the counter) "believes" that it is playing only two minutes. So you begin to play, and the seconds look veeery sloow, and everything seems OK, but -alas- NO! At screen second 28 you get the irritating "two minutes are over" nag screen! Obviously you were dead wrong: the program "knows" the time directly from the timer... you only modified the stupid counter ON THE SCREEN. So it's back to cracking, and now you are angry, and forget the quiet ways of the zen-analyze and begin the heavy cracking you should reserve -if ever- for really complicated schemes. You now start to check the hooked vectors (you did your routinely VECS_save before loading pooldemo in [Soft-ice] and your VECS_compare afterwards) and you see some findings that you believe interesting: vecs c 08 1EFD:84C6 0CD1:17AC <- the clock 09 1EFD:85EC 136A:069C <- the keyboard 22 0BCE:02B1 0BCE:017E <- the terminate That's more like it -you think. Smack at the beginning: the first hooked vector does it! It's good old interrupt_08: the timer_clicker! Some basics for those of you that do not know anything: INT_08 controls indirectly the INT_1C timer interrupt. The 8253 clock chip generates an IRQ_0 hardware interrupt at a rate of 18.2 interrupts per second. This gives control to the ISR (Interrupt Service Routine) that the INT_08 points to... and this should be at 0CD1:17AC, but has been hooked here, by pooldemo, to 1EFD:84C6. One of the actions taken by the INT_08 ISR within the BIOS is to issue a software interrupt call to INT_1C, just in case any software modules within the system have established an intercept. If no intercepts have been established, the default contents of the INT_1C vector point to an iret instruction within the BIOS, so that a null action results. Normally a protectionist would intercept INT_1C, coz at every ISR from INT_08 the CPU would fetch the contents of the corresponding interrupt vector and make an interrupt style call to the code at that address (which should contain the iret at address F000:9876 but can contain any trick they could think of). So -you think- the protectionist hooked here INT_08 directly (a pretty infrequently used protection scheme by the way): What now? A rather drastic measure would be, in such circumstances, to disable the IRQ_0 level timer interrupt, which is controlled by bit 0 of the mask register, at address I/O 0021h. When bit 0 within the mask register is set to 1, no further interrupts will be recognized for this IRQ level. This unfortunately won't work here, but it's an interesting technique per se, so you better learn it anyway, just in case you should need it elsewhere: --- Trick to disable the timer ("IRQ_0 masking" by +ORC) --- * prompt $t and hit ENTER a few times, see how the dos_clock is merrily ticking along? * enter DEBUG.COM * Assemble using the command 'a' - a in al,21 or al,1 out 21,al ret RETURN RETURN <- twice to exit immediate assembler - g 100 <- to run the tiny program. - q <- to quit debug. prompt $t is still on: hit ENTER a few times: whoa! The clock has stopped advancing! Compliments: you loaded the current mask register's contents into AL, you set the mask bit in the bit 0 position (which corresponds to IRQ_0) at then updated the value back to the mask register. When you are ready to activate IRQ_0 events again, reenter DEBUG, run the following and then reset the clock you stopped with DOS TIME command: - a in al,21 and al,fe out 21,al ret RETURN twice - g 100 - q A word of caution: with the timer click disabled some processes will not operate correctly: once you access the diskette drive, the motor will continue to run indefinitely afterwards, etcetera. ------------------------------------------------------- Unfortunately the above technique cannot work with our [pooldemo.exe], where you now are looking closely to the INT_08 hook you found, believing that it hides the protection scheme: herein you find immediately the EoI (End_of_interrupt: MOV AL,20h... OUT 20h,AL). Both controllers have a second port address at 20h (or 0a0h), from which the instructions are given. The most important is the EoI command (20h). This instruction indicates the end of the interrupt handler and frees up the corresponding controller for the next interrupt. If somebody writes a new custom interrupt handler (as many protectionists do), it's up to him to see to it that at the end of the handler the EoI command (20h) is written to either port 20h or port 0a0h. After the EoI follow the usual pushes, then some CALLS then a call that issues some OUT 40,AL that look like timer refreshing (OUT transfers data to an output port and ports 40-42 correspond to the Timer/counter). Some do_maintenance follows, then a double CALL, one more conditional CALL and then a "mysterious" call FAR CS:[AA91] on which depends a byte PTR[970C] that decides another final CALL... then the routine pops all registers and irets away. Ah! You say, and begin disassembling, reverse engineering and looking inside each suspect call (the quicker method in these cases is to breakpoint calls on entrance and see if you find the one that's only called at the awakening of the time limit protection). You work, and work, and work... and eventually find nothing at all, coz the protection of this program is NOT HERE! Back to the zen-analyze of the snap printings... we forsake it too soon, as you will see. If you watch with more attention the compare locations for the range DS:0 DS:FFFF you 'll notice that one of them changes relatively slowly from 0 to 1 to 2 to 3 and so on... the precedent location changes very quickly, and runs the complete cycle 0...FF. That's a counter, at locations DS:0009 and DS:000A! How long will it tick along? Well, we saw above that the "charge" every second is 3C, so it will be x3C*x78=x1C20, coz x78 is 120 seconds, i.e. the two minutes time limit. Now search this 1C20 value around inside the code (protections are most of the time at the beginning of the CS:offset section), and you 'll find quickly what follows: The protection in [pooldemo.exe] is at code_locations CS:0A8A 813E20A7201C CMP WORD PTR [A720], 1C20 compare location A720 with limit 1C20 CS:0A90 7C07 JL okay_play_a_little_more CS:0A92 E834FD CALL beggar_off_time_is_up BINGO!: FOUND! Now let's quickly crack it: ------------------------------------------------ CRACKING POOLDEMO.EXE (by +ORC, January 1996) ren pooldemo.exe pooldemo.ded symdeb pooldemo.ded - s cs:0 Lffff 81 3E 20 A7 20 1C xxxx:yyyy <- this is the answer of the debugger - e xxxx:yyyy+5 4C <- this time limit is much better - w - q ren pooldemo.ded pooldemo.exe ------------------------------------------------- We have done here a "weak" crack: we limited ourselves to accept a (better) time limit, changing it from 1C20 to 4C20 (4 minutes instead of two). We could obviously have done a more radical crack if we had changed the JL (jump lower) instruction in a JMP (jump anyway) instruction. In this case it would have worked, but for reasons that will be explained in lesson 4, you should choose a rather delicate approach in cracking when you deal with time-limit protection schemes. As you have seen, in this artificial cracking session we found the protection scheme after a little snooping around. But, as you will see in the hands on part, there are always MANY ways to crack a single protection scheme. You could -for instance- have found this protection the other way round: set a trace on memory range for the program, restricting the trace to the first part of it (say CS:0 to CS:1000, if you do not fetch anything you can always try the other blocks). Breakpoint at the nag screen, have a look at the last 300-400 backtraced instructions, if you did not move anything, everything will follow a repetitive pattern, until the protection snaps on: ... JL 0A99 CMP BYTE PTR [A72A],01 ... JL 0A99 CMP BYTE PTR [A72A],01 ... for ages and ages and then... ... JL 0A99 E834FD CALL 0759 <- BINGO! (CALL beggar_off_time_is_up) ... there it is, found the other way round. (But this apparently better method is unfortunately very unstable: it depends on your timing of the breaking in and on the distance between protection and nag screen, therefore the somehow more complicated, but more sure previous one should be favoured). The reason why "minimal" approaches in cracking are often more successful than heavy vector_cracking, is that the programs are hardly ever "overprotected", and therefore the protections are seldom difficult to find (and those that are really worth cracking for study reasons). Sometime you don't even need to crack anything at all! Some applications are fully functional -per se-, but have been crippled in a hurry in order to release them as demos. The commercial programmers want only money, do not even try to understand our zen ways, and do not care at all for a well done job. That means, among other things, that the hard disk of the user will be cluttered with files that the main program module never calls. A typical example of this sloppy method is the demo of [Panzer General] from SSI that appeared in the summer '95. This was in reality no less than the complete beta version of the game: you just had to substitute to one of the two "allowed" scenarios one of the 20 or more scenarios of the beta version in order to play them freely... you didn't ever need to crack! The pooldemo crack example above should not discourage you from cracking intuitively. Be careful! Perform a thoroughly zen_analyze before attempting deeper methods: do remember that you want to crack the protection scheme SOMEHOW, and not necessarily following the same line of thought that the programmer eventually WANTED YOU TO CRACK IT with. Well, that's it for this lesson, reader. Not all lessons of my tutorial are on the Web. You 'll obtain the missing lessons IF AND ONLY IF you mail me back (via anon.penet.fi) with some tricks of the trade I may not know that YOU discovered. Mostly I'll actually know them already, but if they are really new you'll be given full credit, and even if they are not, should I judge that you "rediscovered" them with your work, or that you actually did good work on them, I'll send you the remaining lessons nevertheless. Your suggestions and critics on the whole crap I wrote are also welcomed. E-mail +ORC +ORC an526164@anon.penet.fi HOW TO CRACK, by +ORC, A TUTORIAL --------------------------------------------------------------------------- Lesson 2: tools and tricks of the trade --------------------------------------------------------------------------- [INDY.EXE] -------------------------------------- LOST IN THE DARK CODEWOODS When you break into a program you end up in portions of code that are unfamiliar to you. It is also not uncommon for the breakpoints to occur outside of the confines of the program you want to crack. Getting your bearings is, in these cases, very important. One of the handiest utilities is the memory dump tool -it tells you where all the device drivers and TSR are loaded, in which memory locations the program you are cracking dwells, how much memory is left and what the next program load point is. The tools you use should report on the following: - the contents of interrupt vectors - the state of the BIOS data area, beginning at address 40:0 - internal structures within DOS, such as the MCB chain, the SFT (System File Table) chain, the chain of installed device drivers, the PSPs and memory allocations associated with installed TSRs - memory allocation statistic from XMS and EMS drivers When seeking to understand a section of foreign code, you must be especially careful to seek the real intent of the code. Consider using a profiler prior to undertaking an analysis of an unfamiliar program. This will help you by ensuring that you don't waste time studying sections of the program that aren't even involved in the protection scheme you are chasing down. Using a utility that charts a program's calling hierarchy can give you an important perspective on how your babe conducts its internal operations. YOUR DEBUGGER: YOUR FAVOURITE TOOL First and foremost, your debugger must be designed for use with resident modules (or must be itself a resident module). Trying to crack with simplistic [debug.com] is a sure way to get absolutely nowhere. We recommend Softice.exe from Nu-Mega technologies (Version 2.6 [S-Ice.exe] has been cracked by MARQUIS DE SOIREE and its vastly available on the Web). You could also use [Periscope] or [Codeview] or Borland's Turbodebugger... all these programs have been boldly cracked and/or distributed and are now on the Web for free... learn how to use YAHOO and find them. In emergency cases you could fix some quick crack using [debug] or [symdeb], but, as said above, most of the time these older debuggers won't do. I'll nevertheless ALWAYS give the final crack procedure for [debug.com], in order to permit even lusers to crack programs. When you first smell a protection, it can be tempting to immediately begin your crack using invasive types of techniques. While there is certainly nothing wrong with this approach, provided that you are fairly familiar with the protection scheme used, going in too deep too soon can be a problem when you don't have a strong hunch. Most of the time you'll end up missing important details. So first of all sit down and ponder... that's the zen-way, the only one that really works. Single-stepping is expensive, not only because of the time it requires but also because of the amount of detail with which you must contend. Your immediate goal is to home in on the protection scheme through a series of successively refined traps, your broader aim is to get an overview idea of the program's action... the wise use of breakpoints will condense these minutiae into an understandable form. The first step is to try to identify the section of the program where the protection scheme is snapping. Once you are able to isolate a certain section of a program, breakpoints can be used to gather a trace history of the program's execution. If your debugger sports a backtrace buffer, logging window, or similar feature, by all means learn how to use it. The debugger it's your best weapon, you must know all the possibilities it offers and all the capabilities it possesses. Having a debugger's display output echoed to a printer is another possibility. Using breakpoints is beneficial for two basic reasons: speed and reduction of detail. Manual single-stepping is invaluable when you are close to the protection scheme, but too much of it will bore you to death. When selecting breakpoint locations and the types of breakpoint to use, it is important to step back once more, drink a cool Martini-Wodka (use only Moskovskaja: non-russian Wodkas are appalling) and ask yourself: "What is this going to tell me?" and "What else will I need to know once the break occurs?". MOST IMPORTANT OF ALL: "Is my current cracking approach the simplest and most direct?", coz you do not want to waste precious cracking time. When devising a set of breakpoints it is wise to consider how "a trail of bread crumbs" can be left. Not allowing for an execution chronicle from the start can mean having to restart a cracking session. Setting breakpoints on certain software interrupt calls is an excellent way to get an overview of a program's operations. The INT_21 DOS services interrupt is probably the most universal useful of these, with BIOS interrupts such as the INT_13 (BIOS Disk services) and INT_16 (BIOS keyboard services) useful for specific cracking. When working with a debugger, evaluative breakpoints are usually your best shot. To avoid having to deal with a plethora of calls, you would want to have a debugger capable of being told to "break on any INT_21 call except where AH == 2C or AH == 0B". A real understanding of the working of a program is surely important, but don't overdo it! To reverse-engineer even a small program can involve many hours of analysis and documentation work. If you'll not be able to use the zen-cracking techniques described in this tutorial (sadly not everybody can) pace yourself and make sure your chair is comfortable: you'll be sitting for quite a spell. Much of the work involved in reverse-engineering consist of chasing down tentacles. In order to understand the operations of one function, you must understand what happens within each of the functions it calls- its child functions. To understand these child functions you must study their children; and so on down the calling hierarchy tree. Then there is the data. Tracing tentacles based on a program's calling hierarchy is a directed process. Each function you encounter is basically a list of other functions you must reckon with. When it comes to analyzing a function's interrelationship with the program's data structure, no such list is provided. You must have instinct, feeling and luck. Data analysis requires more of a broad-based inquisition. For each memory variable you are interested in, you must survey all functions to determine which ones read and write that variable. The use of memory conditional breakpoints and of a disassembler that builds a cross-reference table can make this task a lot easier. (Use Sourcer! It's a fairly good tool and version 4.08 of [sr.exe] has been long ago cracked and distributed on the Web). ALL SYSTEM CALLS IN ONE LOCATION Remember that if the program you are cracking was written in assembler in the first place (very unlikely knowing the laziness of to_days programmers), system calls are probably made directly from the functions which need them. But when a program is developed in a high-level language, it is more likely that common library functions will be used for many operations involving system calls. When a program makes all of its INT_21 calls from the same location, you know that this is certainly the case. Now, what happens sometimes is that the programmers write the whole application in a overbloated language like C++, but are afterwards compelled to "speed up" critical sections of the code writing them in assembler. And loo! A section where you repeatedly find assembler crafted patches is precisely the protection scheme! So you could have a program with all INT_21 calls from the same location but for one or two calls which are coming out of the section where the morons have "hidden" their protection strategy. By just "looking" at the dead code of a program, you should be capable to tell wich parts have been "added on" in a later phase. They presents themselves as unevenness and irregularities, especially if you use an utility that represents graphicallly the code of a program. Protections are often added on at the end of the development. Should you determine that the system calls relevant to your cracking are made from common library functions, all is not lost. The specific function from which these library calls were made, the function you are seeking to locate, is executing at some point in between these calls. Break in with your debugger at the end of the first system call, just where it is returning to the point of call. From there, trace through the remainder of the common library routine until it returns to its caller. In short order, you should find yourself in the function you need to see. The trick is to be able to identify it for what it is. ASCIIZ IN CODE In the interest of gaining an overall familiarity with the program you want to crack, it can be enlightening to use a hex dump utility to examine the message strings contained within the program's binary modules. If the program happens to load its message strings from separate files, your search has just been simplified. Your debugger's memory-dumping feature is one tool that can be useful for this type of exploration. You could also construct a filtering program, which would read a binary file and output all sequences of bytes that are comprised of displayable characters and are over a certain minimum length (the best cracker tools are often the ones you write yourself). When a protection scheme is marked by the issuance of a specific message on the screen, you could go into the program and locate the code that emits this message, and then determine what triggers it. A good way to start the location process is to see if a system call is used to display the string. Interrupt INT_21, INT_10 or INT_29 are usually used to display text messages to the console. When the message's display is not a result of one of these system calls, direct video writing is probably being used. If you know the screen location used, and if that part of video memory is not used for anything else at the time (a big if), a memory write breakpoint could be set on the video buffer address corresponding to the first character's position. If this won't work, use the step-over/step-around tracing technique while watching for the message to appear. Now you found it: from a disassembled listing, you locate the address of the message string and then survey the reminder of the file for any instructions that reference this address. [Sourcer] can generate labels for specific memory locations and a cross-reference table showing where these labelled locations are referenced. Otherwise, load the disassembled listing file into your editor and use its search capabilities. Manually searching for such things in a listing will make you old before your time. CODE AND DATA When stepping through code at the assembler level, watch out for interrupt calls that are followed by data. Sometimes you will find an interrupt call, typically within the range INT_34 to INT_3F, where several bytes immediately following the interrupt instruction will be data rather than code. Be especially suspicious of this type of code-and-data mixture when your debugger's disassembly output of the instructions immediately following an interrupt call doesn't make sense. Sometimes you can determine the offset of the next true instruction by inspecting the following code and data. In other cases, you will have to trace through the interrupt call to see how it accesses the data following the interrupt call instruction and how it manipulates the return address on the stack. HOOKED VECTORS Seeing what interrupt intercepts already exist within a system before running the program you want to crack, as well as what interrupt handlers are established by the target program, can provide useful clues. For example, if a protection establishes an INT_09 intercept just before the snapping of a keyboard verification routine, your range of suspects has just been narrowed significantly. To study the interrupt vector activities of an application, a vector dump map utility is useless. It can't be run while running the application you want to crack. One solution is to run the program under a debugger and watch for system calls to INT_21 functions 25h (set interrupt vector) and 35h (get interrupt vector), but in the event that the program reads and writes interrupt vectors directly, this method will not give you a complete picture. Normally you'll use a spy, trace or "step" utility. APPLYING A MEMORY WRITE BREAKPOINT TO A SPECIFIC VECTOR OR TO THE ENTIRE TABLE is another way to deal with this. Note that some sort of direct vector writing must be occurring if a vector change is detected between system calls. If a vector change is detected during a system call but it isn't function 25h of INT_21, suspect that an IRQ handler may be effecting the change. LITTLE TRICKS OF THE TRADE: * determining interrupt vector addresses **************** How do you determine the interrupt vector addresses? As example let's find the address of the INT_21 interrupt vector. Since the interrupt vector table starts at address 0000:0000 (easy to remember, isn't it?) and there are four bytes per vector, the basic process is to multiply the interrupt number four times and use the result at the offset (on segment zero). 21h + 21h = 42h 42h + 42h = 84h The int_21 vector is located at address 0000:0084 You could also use a calculator, for instance, the address of INT_63 is 63h*4=18ch -> 0000:018C * address conversion *************************************** After a painstaking cracking session, you have finally determined that a byte of memory at address 6049:891C is the trigger. But when you isolate the offending instruction, you find that the address it is generating when the protection occur is different, being 6109:7D1C instead! How can this be? An 80x86 type CPU, when running in real or VM86 mode, uses what is known as segment:offset type addressing. One side effect of this addressing method is that one physical address can be equivalent to many different segment:offset addresses. To find the PHYSICAL ADDRESS for a given segment:offset do the following: - convert the segment portion of the address to a 1-based number by multiplying it by 16 (x10)... it's easy: add 0 at the right end of the number!... 6049 -> 60490 6109 -> 61090 now all you have to do is to add this value to the offset value 60490+891C -> 68DAC 61090+7D1C -> 68DAC <- Got it? And the other way round? If you have a physical address, say 19AC3, and you want to obtain a segment:offset address you must first of all decide in which segment you want the address... if, say, you choose segment 16CC, you proceed as follows: 16CC -> 16CC0 19AC3-16CC0 = 2E03 (offset) address for 19AC3 in segment 16CC = 16CC:2E03 TOOLS OF THE TRADE Before starting this section, for those of you that do not know anything, here is the ARCHIE way you get all the program that do EXIST on the planet: e-mail following 1) (address) archie@archie.univ-rennes1.fr I use this french archie, but you can get a worldwide list using the metacommand "servers" 2) (text) set search sub <- anywhere in string set maxhits 140 <- (100-1000) set maxhitspm 15 <- not just 1 file all over find stepdos <- search e.g. this file Wait two hours, get your post and ftp the file you wanted (and YES!, you 'll find also EVERYTHING else for free on the Web). You could, instead of using archie, also learn how to use YAHOO. [MEMSCAN.EXE] One of the most fascinating tools that I have ever seen is a (very old) program: MEMSCAN.EXE. This program was originally written in 1988 by Scott A. Mebust, running in CGA. It's a "visual" utility: it enables you to see graphically the 1-meg of PC memory in 8 kbyte chunks. It's a powerful tool in order to locate quickly bit mapped graphics and other 'objects' in memory, like program data tables, stack areas, code areas, available RAM, etc. I used this great idea to create (in C) my own tools: a "dead_programs scanner" and an ameliorate version of Memscan itself. Looking at the VISUAL STRUCTURE of a program it's a great help when you'll crack higher levels. [TRACKMEM.COM] A very good tool by James W.Birdsall, tracks memory usage of programs (EMS, XMS, conventional). [SCANCODE.COM] "THE" scancode lister, by the code_masters from clockwork software. The must utility for crackers that do not learn all scancodes by heart. [MAP.EXE] Actually "MAP2", THE memory mapper from the code_masters at clockwork software. It's a very good tool and an interesting one too, coz you get it with the "Nigel" nag screens. They are not difficult to remove (a "passletter" protection scheme, you'll learn how to find and remove it from [Map.exe] in LESSON 3.2). [FILEDUMP.COM] [HEXDUMP.COM] [TDUMP.EXE] [DUMP.EXE] There are hundred of file dump utilities, coz file dumping is one of the first exercise they learn you at C-school. Hexdump.com is 558 bytes long, Tdump.exe 120.704, pick the one you like better or write your own (even better). Filedump.com, by Daniel M.O'Brien, 1046 bytes long, it's nice. [SPRAY.COM] That's a good crack utility indeed! This 1989 program by Daniel M.O'Brien gives you a "post-mortem" picture of your memory. You redirect it to <myfile> and study it at ease. It's difficult to say how many hours of cracking it did spare me (you should study the program, only 252 bytes long, and will have to modify it a bit, coz it's pretty primitive, in the original version, for instance, the redirection to the printer works only if there is NO SPACE between "spray" and ">"). [VEXE.EXE] A good EXE files analyzer, useful for windows programs too (see --> LESSON 7). Some of its functions are present in TDUMP.EXE too. This 1991 program by S.Krupa it's sometimes very useful. [SNOOP UTILITIES --> KGB.EXE INTMON.EXE INTRSPY.EXE etc...] [TRACE UTILITIES --> TRACE.EXE STEPDOS.EXE etc...] A must to study the "calling hierarchy" of an unknown program. KGB.EXE, a 1992 program by Petr Horàk could easily be the best one, and comes with source code(!). I'll teach you how to crack without any of them (you do not need them if you zen- crack), but they can nevertheless be very useful in some situations. Stepdos.exe, by Mike Parker, is a excellent program: a pleasure to crack in order to use it for slightly different purposes :=) [SOURCERING UTILITIES] SR.EXE can be used for sourcering unknown programs. It's a fairly good sourcering tool. Version 4.08 has been cracked (it's a "ORIGINAL NUMBERCODE" protected program) and distributed on the Web, so you should easily find it. This said, you should NEVER use such a brute force approach, unless you are really desperate: I'll teach you how to crack without sourcering (you don't need to sourcer if you zen-crack). [HEXEDITORS] Every idiot has written at least one hexeditor, and you can find very bad tools everywhere (the SIMTEL collection, on the Web, lists at least 35 hexeditors). I suggest you write your own and contribute to the flood, or (better) get PSEDIT.EXE, a good 1990 program by Gary C. Crider (Parity Solutions, 1903 Pavia Ct. Arlington, TX 76006... sometimes even americans can write good programs). If you do use it (as you should) disapt the nag screen as small exercise in cracking. [DEBUGGER] Your best friend in cracking, your weapon, your hidecloak... I suggest [Softice.exe] from Nu-Mega technologies (Version 2.6 has been cracked by MARQUIS DE SOIREE and its vastly available on the Web). You could also use [Periscope] or [Codeview] or Borland's Turbodebugger... all these programs have been boldly cracked and/or distributed and are now on the Web for free... learn how to use ARCHIE and YAHOO in order to find them. Your debugger is the only tool you 'll REALLY need, believe me. So choose your weapon wisely and learn how to use backtrace ranges and (FOREMOST!) breakpoint on user written qualifications routines. You 'll be able to crack almost EVERYTHING using these features in the right way. You should get all the programs mentioned above (all the programs that EXIST for that matter) for free on the Web. Use them, but also modify them recklessly! REMEMBER THAT YOU ARE (GOING TO BE) A CRACKER! The first programs you should crack and modify are therefore your very tools! So steal the code of the best tools you find! Snatch the best routines and change them for the better! That's the whole point in cracking: a mission to IMPROVE the best accomplishments of humanity's genius :=) HOW TO CRACK, ZEN-CRACKING You 'll learn, beginning with next lesson, how to crack systematically the different protection schemes: paper & password protections, time protections, access protections. At the end of the "methodolocical" part, you'll be able to deprotect programs, but you still wont be a cracker. In order to crack higher you must use what I call (lacking a better definition) "zen- cracking". I 'll give you right now an example of this, so that you know what I'm talking about, but -unless you are already capable- you'll have to finish this tutorial part for "normal" cracking before attempting this techniques. Let's zen-crack together a password protection scheme (aka "paper protection", coz you need the original manual of the program in order to answer). This protection is based on the typing, at the nag screen, of the correct sequence of numbers. Our example is a game for the reasons explained in lesson 1, but you 'll find the SAME protection scheme in the access protection procedure of some old Tapestry networks... so do not frown upon games protections. INDIANAPOLIS 500, Papyrus software & Electronic Arts, 1989 It's a rather widespread program, you should therefore find it pretty easily. The nag screen asks for data based on the historical performances of race cars... that means that the answers will consist in two to three digits. Now, the normal way to crack such a program (described in -> lesson 3.1) embodyes following steps: - snap save program memory areas before typing your answer - snap compare after typing, say, "666" - search for the sequence 36,36,36 (i.e. 666) - breakpoint on memory range for reading - look at the program part fetching your data - find the snap procedure - disable it. The above crack it's relatively quick and should be most of the time fairly effective, but there is a better way: the "zen way", the only one that can really enable you to crack high protection schemes. - Run the program and break in at the nag screen - Answer consist of 2-3 digits? Search for "AC" (i.e. the instruction LODSB, load digit of answer in AL) in the area 500 bytes BEFORE and 500 bytes AFTER your position. You'll get some locations. (In the case of INDY 500 you get 6 such locations). - "feel" the locations (that's the tricky part). - OK, you already made it! Here is the protection strategy: 8BBF28A5 MOV DI,[BX+A528]<-- DI points to coded data area :compare_loop AC LODSB <-- load first digit of answer in AL B4FF MOV AH,FF <-- load mask in AH 2A25 SUB AH,[DI] <-- sub coded data from mask and get real answer 47 INC DI <-- ready to get next coded data 3AC4 CMP AL,AH <-- user answer = real answer ? 751A JNZ beggar_off_coz_false_answer 0AC0 OR AL,AL <-- more numbers? 75F2 JNZ compare_loop 59 POP CX <-- all OK, go on, nice guy ... And if the protection scheme had been more far away? And if you cannot "feel" the right one? And if my grandma had wheels? You'll learn it, believe me. Now let's quickly crack this crap. ------------------------------------------------ CRACKING INDY.EXE (by +ORC, January 1996) ren indy.exe indy.ded symdeb indy.ded - s (cs+0000):0 Lffff B4 FF 2A 25 47 3A C4 75 1A xxxx:yyyy <-- this is the answer of the debugger - s (cs+1000):0 Lffff B4 FF 2A 25 47 3A C4 75 1A (nothing, but you must be sure there isn't a mirror) - e xxxx:yyyy+8 00 <-- "JNZ 1A ahead" changes to "JNZ 0" - w - q ren indy.ded indy.exe ------------------------------------------------- Cracked: you just changed the JNZ beggar_off instruction in a JNZ go_ahead_anyway. Nice, isnt'it? WHY WE CRACK Strange as it may seem, the reasons for cracking are very important for the success of our task. We (at least we old crackers) crack AGAINST society, and OPPOSING laws and conventions. We usually DO NOT crack for money or for other "commercial" reasons (just sometimes, and we are expensive: I have plenty of money already and my services are VERY expensive if you need an aimed deprotection). But in general we don't care much for money and -as you can see- I am giving away the basis of what I know for free with this tutorial. The programs we crack should be made free for everybody, even if we spent some of our time deprotecting them. We could not care less of the commercial value of a given program, not to mention the holy work of the ethical programmers... we program ourselves, but only because we LIKE it... if somebody does something only in order to gain money, he does not deserve anything. It's the mind challenge that counts, NEVER the profit! (Even if you can make good use of the cracked programs and even if -as I said- there is at times a personal profit). This is an indispensable attitude! Only a non-mercantile mind can leap forward to the "satori" knowledge that you desperately need if you want to crack quickly and elegantly huge iperbloated monstruosities that somebody else wrote and protected, or if you want to gain access to some hidden information, data that you would like to snoop but that somebody declared "off limits", coz a stupid government, or useless industry sector, or money oriented programmer or dirty lobby of interest decided it. If you do accept the society where we are compelled to live, its awfully egoistic way of life and its dirty "profit" values, you may eventually learn how to disable some simple protections, but you'll never be able to crack in the "right" way. You must learn to despise money, governments, televisions, trends, opinion-makers, public opinion, newspapers and all this preposterous, asinine shit if you want to grasp the noble art, coz in order to be emphatic with the code you must be free from all trivial and petty conventions, strange as it may sound. So you better take a good look around you... you'll find plenty of reasons to hate society and act against it, plenty of sparks to crackle programs in the right way... Hope all this did not sound too cretin. Well, that's it for this lesson, reader. Not all lessons of my tutorial are on the Web. You 'll obtain the missing lessons IF AND ONLY IF you mail me back (via anon.penet.fi) with some tricks of the trade I may not know that YOU discovered. Mostly I'll actually know them already, but if they are really new you'll be given full credit, and even if they are not, should I judge that you "rediscovered" them with your work, or that you actually did good work on them, I'll send you the remaining lessons nevertheless. Your suggestions and critics on the whole crap I wrote are also welcomed. E-mail +ORC +ORC an526164@anon.penet.fi HOW TO CRACK, by +ORC, A TUTORIAL --------------------------------------------------------------------------- Lesson 3.1: hands on, paper protections (1) --------------------------------------------------------------------------- [UMS.EXE] [LIGHTSPD.EXE] [GENERAL.EXE] -------------------------------------- SOME PROBLEMS WITH INTEL's INT The INT instruction is the source of a great deal of the flexibility in the PC architecture, because the ability to get and set interrupt vectors means that system services (included DOS itself) are infinitely extensible, replaceable and MONITORABLE. Yet the Int instruction is also remarkably inflexible in two key ways: - an interrupt handler DOES NOT KNOW which interrupt number invoked it. - the int instruction itself expects an IMMEDIATE operand: you cannot write MOV AX,x21, and then INT AX; you must write INT x21. That would be very good indeed for us cracker... unfortunately many high level language compilers compile interrupts into PUSHF and FAR CALL instruction sequences, rather than do an actual INT. Another method is to PUSH the address of the handler on the stack and do RETF to it. Some protection schemes attempt to disguise interrupt calls, 1) camouflaging the code, 2) putting in substitute interrupt instructions which look harmless and modifying them "on the fly" or 3) replicating whole interrupt routines inside the code. This is particularly frequent in the various "disk access" protection schemes that utilize INT_13 (the "disk" interrupt) and will therefore be thoroughly explained in -> lesson 5. A LITTLE BASIC ASSEMBLER In order to understand the protection schemes and to defeat them, you must acquire a passing knowledge of assembler, the "machine language" code. You can find a lot of good, well explained code for free: viruses are one of the best sources for good "tight and tricky" assembler code. You can find the source code of almost all viruses on the web: oddly all the would be hackers seem to have an aberrant passion for this kind of stuff instead of studying cracking techniques. But there are millions of lines of good explained "commercial" assembler code on the net, just fish it out and study it: the more you know, the better you crack. I'll restrict myself to some observations, sprinkled throughout this tutorial. Let's start with some must_know: ------------------------ STRINGS ---------------------------- The string instructions are quite powerful (and play a great role in password protection scheme). ALL of them have the property that: 1) The source of data is described by the combination DS:SI 2) The destination of data is described by the combination ES:DI 3) As part of the operation, the SI and/or DI register(s) is(are) incremented or decremented so the operation can be repeated. ------------------------- JUMPS ----------------------------- JZ ero means what it says JNZ ero means what it says JG reater means "if the SIGNED difference is positive" JA bove means "if the UNSIGNED difference is positive" JL ess means "if the SIGNED difference is negative" JB elow means "if the UNSIGNED difference is negative" JC arry assembles the same as JB, it's a matter of aesthetic choice CRACKING PASSWORD PROTECTED PROGRAMS Refer to lesson one in order to understand why we are using games instead of commercial applications as learn material: they offer the same protection used by the more "serious" applications (or BBS & servers) although inside files that are small enough to be cracked without loosing too much time. A whole series of programs employ copy protection schemes based upon the possess of the original manual or instructions. That's obviously not a very big protection -per se- coz everybody nowadays has access to a photocopier, but it's bothering enough to motivate our cracks and -besides- you'll find the same schemes lurking in many other password protected programs. Usually, at the beginning of the program, a "nag screen" requires a word that the user can find somewhere inside the original manual, something like: "please type in the first word of line 3 of point 3.3.2". Often, in order to avoid mistakes, the program indicates the first letter of the password... the user must therefore only fill the remaining letters. Some examples, some cracks: --------------------------------------------------- UMS (Universal Military Simulator) version 1 by Dr Ezra SIDRAN (c) 1987 Intergalactic Development European Union: Rainbird Software United States: Firebird Software --------------------------------------------------- This very old EGA program is one of the first I cracked in my youth, and it's very interesting coz it employs a very basilar protection scheme (a "PRIMITIVE"! More than 80% of the protection schemes used to day (January 1996) are directly derived from one of the 12 primitives. The nag screen snaps at the beginning and keeps indefinitely asking your answer, only the use of CTRL+C will bring you out of it, back to DOS. That's a clear sign of older protection schemes: newer schemes let you in for only 3 attempts or even only one, and pop out to the OS if you fail. In UMS, besides, there is no "first letter" aid, a later improvement. The cracking procedure for password protected programs is, first of all, to find out where are stored the letters that you type in. So examine your memory map, find out where the program dwells in memory, do a snap save of these memory areas and a series of snap compares as you type your password in. Strangely enough, in the case of UMS, as you type your password there seems to be no difference at all in the memory locations where this program dwells... yet the data must be somewhere... Usually such a situation is a clear sign that an hooked interrupt is used to hide the data. Checking the hooked vectors you find out the following: vecs 00, 02, 22 are hooked where needs be vecs 34-3D are hooked at xxxx:0 vec 3E is hooked at xxxx:00CA Ha! Let's have a closer look at this bizarre 3E hook. Let's search for some words used in the nag_screen and then let's dump the area where we find them (in UMS that will be at 3E_hook address + 7656) and loo! You'll see the content of the nag screen and, immediately afterwards, ALL the passwords "in extenso", i.e. not encoded, not scrambled, nothing at all... THERE THEY ARE (that's a very old protection scheme indeed). You could now, for instance, easily patch all the different passwords to (for instance) "PASS", and this would work... it's a very primitive protection, as we said, nevertheless the use of a hooked vector as hiding place for the protection code is not yet obsolete... we'll find it elsewhere, in many "more modern" programs. Now let's go deeper and examine the "compare" mechanism, we want to crack, here, not just to patch. Password protected programs (and access protection routines for server and BBS, for that matter) have quite a lot of weak points. The most obvious one (you 'll find out the other when you'll high crack) is that they MUST compare the password of the user with the original one(s). So you do not need to steal a password, you just need to "ear" the echo of the original one in the memory locations used for the compare, or, and that's more correct, to crack the compare mechanism itself so as to make it let you in even with a totally false password. The compare mechanism of UMS can be found setting a breakpoint on the memory range that covers the three locations where the password is stored (and you 'll find these with your search capabilities and with a pair of snap compares): ES:0F8E (here you 'll see a copy of the password that the program is asking) ES:0F5C (here you 'll see a copy of the password that the user types in) INT_3E hook_address + 7656 (here are all the possible passwords in extenso). Here is how the protection scheme looks out: MOV CX,FFFF Charge MAX in CX REPNZ SCASB Scan ES:DI (the user password) NOT CX Now CX holds the number of the character that the user typed in MOV DI,SI Real password offset to DI LDS SI,[BP+0A] User password offset in SI REPZ CMPSB Compares DS:SI with ES:DI (user password and real password) then snap out at CX=0 or at char_different, whichever comes first. Nice, we found the compare schema... how do we crack it now? There are many elegant solutions, but let's remain on a basic level... you look at the code that follows the CMPSB searching the "snapping schema"... here it is immediately afterwards (that's the case in most of the primitives). Remember: we sprung out of the CMPSB check at the first different char, OR at the end of the count of the user chars. Here it is what follows: MOV AL,[SI-01] loads in AL the before_different char of the user password (should be zero) SUB AL,ES:[DI-01] subs with the before_different char of the real password (should be zero) CBW zero flag set, "TRUE", if OK_match Well let's now look for the next JZ near (it's a "74" code) CS:IP 740D JZ location no_good Wait, let's continue a little... is there another check (often you have a double check on DI)... yes there is! CS:IP 7590 JNZ location no_good Cracking such a schema is very easy: you just need to substitute 75 to 74 and 74 to 75: transform your JZ in a JNZ and the JNZ in a JZ... now you will always pass, no matter what you write, unless you exactly guess the password! Now let's quickly crack it: ------------------------------------------------ CRACKING UMS.EXE (by +ORC, January 1996) ren ums.exe ums.ded symdeb ums.ded - s (cs+0000):0 Lffff 74 0D 1E B8 C2 3F (nothing) - s (cs+1000):0 Lffff 74 0D 1E B8 C2 3F (nothing) - s (cs+2000):0 lffff 74 0D 1E B8 C2 3F xxxx:yyyy (this is the answer of the debugger) - e xxxx:yyyy 75 - e xxxx:yyyy+17 74 - w - q ren ums.ded ums.exe ------------------------------------------------- In the debug/symdeb crack above we use as search string the bytes comprising and following immediately the first JZ. I know, I know... we saw them in [Soft-ice] and we could have modified them there, but I'm teaching also pupils who may not have [Soft-ice]. Note that the program is x431A0 bytes long, and therefore has a BX=4 sectors adding to the CX=31A0 in the initial registers... that's the reason I wanted to examine all the sectors (even if I knew that the snap was in sector (cs+2000): that's good practice! If you do not find your string in the first sector you must search for it in the next sectors, till you find it, coz in many programs there may be MORE THAN ONE repetitions of the same schema (more about this double check later). That's it, pupils, that's the way to crack old [UMS.EXE]. Let's go over, now, to more elaborate and more modern password protection schemes. -------------------------------------------------------- LIGHTSPEED, from Microprose (we crack here version 461.01) -------------------------------------------------------- This program, released in 1990, operates a more "modern" variation of the previous scheme. You 'll find this variation in many access routines of remote servers (and this makes it very interesting indeed). Let's begin as usual, with our hooked vectors examination and our snap compares. Hooked vectors: 00, 08, 1B, 22, 23: nothing particular. The snap_comparisons of the main memory area -as you type the password in- gives more than six pages of changing locations... that's clearly much too much to examine. What now? Sit down, have a Martini Wodka (I'm afraid that only Moskovskaja 'll do) and meditate. Get the memory map of the program's layout. Start anew: snap_save (before typing anything in). Type as password "ABCDE". Get the print of the snap compares. Sit down, sip Martini Wodka, relax. You know that the code for A is x41, for B x42, for C x43 and so on... and in the snap_compares, that you made between letters, you 'll have only some locations with these values changing. Focus on these. You 'll soon enough find out that for LIGHTSPEED absolute location (in my computer) 404307, i.e.: relative locations (in my computer) 30BE:F857 or 4043:0007 evoke the characters you type, i.e. something like ----------------------------------------------------- F855 F856 F857 F858 F859... 41 3E first_ready_letter your_1st_letter your_2nd_one... ----------------------------------------------------- Inspecting the same prints, you 'll find out that absolute location 30C64 (imc) or relative location 30BE:F83E evokes the LAST character you typed in. The relative code line is: CS:0097 MOV AX,[BP-08] where SS:F83E = 00+letter_code Now breakpoint at these locations and investigate what's going on (for instance, the instruction that follows is CS:009A MOV [BX], AX and this means that the code of the letter you just typed in will be now copied in BX=F85A. What else can you do? Time to use a little intuition: look for an instruction "CMP AX,000D", which is the typical "IF the user hits ENTER then" instruction, coz "x1D" its the ENTER keystroke. This must be somewhere around here. Ha! You 'll soon enough find the line CS:0073 3D0D00 CMP AX,000D And now the way is open to the crack. But YOU DO NOT NEED ALL THIS! Since the password protection schemes are -as I told you- all more or less the same, I would suggest that you use first of all following trick: in the largest part of the program (use memory map to see where the program dwells) search the "F3A6" sequence, that's instruction REPZ CMPSB. In the case of Lightspd you 'll get as answer FOUR addresses with this instruction: (pgsg=program main segment) pgsg:C6F9 pgsg:E5CA pgsg:E63E pgsg:EAB0 There you are! Only four... have a short look at each of them: you 'll see that the second one (pgsg:E5CA) is the "good" one. The compare mechanism in this program of 1990 it's more or less the same as in 1987'UMS (and do believe me: the same mechanism is still in use to day (1996)! B9FFFF MOV CX,FFFF charge Max in CX F2AE REPNZ SCASB this scans ES:DI (the original password) F7D1 NOT CX so many chars in the original pw 2BF9 SUB DI,CX change DI for compare F3A6 REPZ CMPSB compares DS:SI with ES:DI (real pw with user pw) then snaps out at CX=0 or at char_differs See how easy? They all use the same old tricks the lazy bastards! Here the section is preceded by a small routine to lowercase the user password, coz the original muster is always lowercased. Now you would like, may be, to breakpoint at one of these locations, in order to stop the program "in the snap area" and inspect the snap mechanism... that WILL NOT DO with a "fixed" breakpoint, coz these locations are called by the snap with a different segment:offset numeration as the one you found (that's old dos magic). So you MUST first set a memory_read/write breakpoint on these locations, and then get at them at the snap. Now you can find out the segment:offset used by the snap and only now you'll be able to set a fixed breakpoint (for instance on the NOT CX instruction). Now run the program and breakpoint in: have a dump of the ES:DI and see the original password. How nice! We have now the original password in extenso in our memory dump window. That's the "echo". By the way, there is a whole school of cracking devoted to find and use these echoes... we work on different paths, nevertheless password fishing can be interesting: where are the password stored? From which locations do they come from? A common practice of the protectionists is to hide them in different files, far away, or in hooked vectors, or in SMC parts. This is a program of 1990, that differs in respect to UMS: the passwords are not "hidden" inside a hooked vector, coz that's a pretty stupid protection: any hexdump utility would still permit you to see them. Here the passwords are encoded (albeit in a very primitive manner): looking for them (with memory range breakpoints) you'll quickly find a section of the program code that looks like this: sg:0118 8C 91 9D 95 9B 8D 00 B8 EC 94 9B 8D 8F 8B 9B sg:0128 94 9B 8D 00 AE EC 9C 9B 8A 9B 86 00 A9 EC 91 This is a typical encoded matrix, with clear 00 fences between the encoded passwords. Ha! If all codes where so easy to crack! This is no better than children's crypt! It's a NEG matrix! And there is direct correspondence: 91=6F="o"; 92=6E="n"; 93=6D="m" and so on... Ha! Let's now leave the "hidden" passwords and proceed with our cracking... let's follow the snap procedure after the REPZ CMPSB instruction looking for the "jump to OK" instruction... F3A6 REPZ CMPSB ; compares DS:SI with ES:DI 7405 JZ preserved_AX=0000 <--- Here the first JZ 1BC0 SBB AX,AX ADFFFF SBB AX,FFFF :preserved_AX=0000 8BF3 MOV SI,BX 8BFA MOV DI,DX 5D POP BP CB RETF .... 83C404 ADD SP,+04 0BC0 OR AX,AX 7509 JNZ 0276 <------ And here it is! Now, remembering the UMS crack, you would probably want to change the JZ instruction in a JNZ instruction (you tried it on the fly INSIDE [Soft-Ice] and it did work!), the "74" with a "75" also. And then you would like to change the JNZ instruction in a JZ instruction... Please feel free to try it... it will NOT work! (You will not even find the second JNZ in the program code). You should always be aware of the SMC (self modifying code) protections: parts of the code my be decrypted "on the fly", as needs arise, by the program. The code you modify while the program is running may be different from the code of the "dead" program. Here we have a small "improvement" of the primitive: the same instruction is used as "muster" for manipulation of other parts of the program... if you do change it in a JNZ you get an overlay message and the program pops out with instability! You cannot easily modify the JNZ instruction either, coz the part after the RETF will be compiled "on the fly" by lightspeed, and you would therefore have to search the decryption mechanism and modify the original encrypted byte somewhere... and may be they do encrypt it twice... and then you must hack all night long... very annoying. So do the following: back to the snap, a sip of martini- Wodka and meditate: loo! The only thing that happens after the JZ, is the setting of the AX register to flag *FALSE* (AX=1... that's what the two SBB instructions do) if the snap went out with a non-zero flag... i.e. if you did not know the password. So let's nop the 5 bytes of the two SBB instructions, or, more elegantly, let's have a INC AX, DEC AX, NOP, INC AX, DEC AX sequence instead of the two SBB! There is a good reason to use a sequence of working instructions instead of a series of NOPs: recent protection schemes "smell" patched nops inside the program and trash everything if they find more than -say- three consecutive NOPs! You should always try to choose THE LESS INTRUSIVE and MORE "CAMOUFLAGED" solution when you crack! Eliminating the two SBBs we get our crack! No need to bother with the second JNZ either... the program will work as if you got the password if you have it AND if you do not (that's better as the previous type of crack -seen for UMS- when you crack computer accesses: hereby the legitimate user will not have any suspects 'coz the system will not shut him out... everybody will access: the good guys and the bad ones... that's nice isn't it?). Now let's quickly crack LIGHTSPD: ------------------------------------------------ CRACKING LIGHTSPEED.EXE (by +ORC, January 1996) ren lightspd.exe lightspd.ded symdeb lightspd.ded - s (cs+0000):0 Lffff 2B F9 F3 A6 74 xxxx:yyyy (this is the answer of the debugger) - s (cs+1000):0 Lffff 2B F9 F3 A6 74 (nothing, but do it nonetheless, just to be sure) - s (cs+2000):0 lffff 2B F9 F3 A6 74 (nothing, just to be sure, now it's enough) - e xxxx:yyyy+6 40 [SPACE] 48 [SP] 90 [SP] 40 [SP] 48 - w - q ren lightspd.ded lightspd.exe ------------------------------------------------- All this CMPSB is very common. Some programs, nevertheless, utilize a password protection scheme that is slightly different, and does not rely on a F3A6 REPZ CMPSB instruction. Let's analyze, for instance, the protection scheme used in the first version of Perfect general I from QQP-White wolf, July 1992. When you break in, at the nag screen, you are in the middle of the BIOS procedures, coz the program expects your input (your password, that's is). You 'll quickly find out (MAP MEMORY USAGE!) that [General.exe] dwells in two main areas; Setting breakpoints on memory write you 'll find out that the memory area "queried" by the protection mechanism is xxxx:1180 to xxxx:11C0 where xxxx represents the second of the memory segments where the program dwells. Now do the following (a very common cracking procedure): * Breakpoint on memory range WRITE for the small memory area touched by the program in querying you for the password. * Breakpoint TRACE on the whole memory range of the MAIN CODE. * Run anew everything It's already done! Now it's your intuition that should work a little: Here the last 9 traces (traces [!], not instructions following on a line) before the calling of the procedure sniffing your memory area: -9 xxxx:0185 7425 JZ somewhere, not taken -8 xxxx:0187 2D1103 SUB AX,0311 -7 xxxx:018A 7430 JZ somewhere, not taken -6 xxxx:018C 2DFD04 SUB AX,04FD -5 xxxx:018F 7443 JZ next_trace, taken -4 xxxx:01D4 E85500 CALL funny_procedure -3 xxxx:022C 803E8F8C11 CMP BYTE PTR[8C8F],11 -2 xxxx:0231 750E JNZ somewhere, not taken -1 xxxx:0233 9A0A0AC33E CALL procedure_that_sniffs our_memory_area Well, the call to funny_procedure followed by a byte compare "feels" fishy from very far away, so let's immediately look at this part of the code of [General.exe] :funny_procedure 803E8F8C11 CMP BYTE PTR[8C8F],11 750E JNZ compare_byte 9A0A0AC333 CALL procedure_that_sniffs 0AC0 OR AL,AL 7405 J2 compare_byte C6068F8C2A MOV BYTE PTR [8C8F],2A :compare_byte 803E8F8C2A CMP BYTE PTR [8C8F],2A 7504 JNZ after_ret B001 MOV AL,01 C3 RET You should be enough crack-able ;=), by this lesson, to notice immediately the inconsistency of the two successive instructions MOV 2A and CMP 2A, coz there would be no sense in comparing the "2A" in order to JNZ to after_ret if you just had the 2A set with the precedent MOV instruction... but the first JNZ jumps to the compare WITHOUT putting the "2A" inside. And "2A" is nothing else as the "*" symbol, commonly used by programmer as "OK"! This protection works in the following way (this is the above code explained): - compare holy_location with 11 - jump non zero to compare holy_loc with "*" - else call sniffing protection part - or al,al (al must be zero, else) - jump zero to compare holy_loc with "*" - if al was zero mov "*" inside holy_loc - compare holy_loc with "*" - if there is a difference then JNZ beggar_off_ugly_copier - else ret_ahead_nice_buyer Now let's quickly crack it: ------------------------------------------------ CRACKING GENERAL.EXE (by +ORC, January 1996) ren general.exe general.ded symdeb general.ded - s (cs+0000):0 Lffff 8C 11 75 0E xxxx:yyyy (this is the answer of the debugger) - e xxxx:yyyy+2 EB [SPACE] 09 - w - q ren general.ded general.exe ------------------------------------------------- And in this way you changed the JNZ to the cmp "*" instruction in a JMP to the mov "*" instruction. So no more nag screens, no more protections... serene, placid, untroubled [general.exe]. Well, that's it for this lesson, reader. Not all lessons of my tutorial are on the Web. You 'll obtain the missing lessons IF AND ONLY IF you mail me back (via anon.penet.fi) with some tricks of the trade I may not know that YOU discovered. Mostly I'll actually know them already, but if they are really new you'll be given full credit, and even if they are not, should I judge that you "rediscovered" them with your work, or that you actually did good work on them, I'll send you the remaining lessons nevertheless. Your suggestions and critics on the whole crap I wrote are also welcomed. E-mail +ORC +ORC an526164@anon.penet.fi HOW TO CRACK, by +ORC, A TUTORIAL --------------------------------------------------------------------------- Lesson 3.2: hands on, paper protections (2) --------------------------------------------------------------------------- [TOP.EXE] [F19.EXE] [POPULOUS.EXE] [MAP.EXE] -------------------------------------- You have seen in the previous lesson that the use of a password protection, independently of the coding and hiding methods used to store them in memory, implies the use of a comparing procedure with the password that the user types in. You therefore have many options to begin your cracking work: - find the location of the user password - find the "echo" in memory of the real password - find the routine that compares both - find the passwords hideout and encryption type - find the go_ahead_nice_buyer exit or jump - find the beggar_off_ugly_copier exit or jump just to name the more obvious ones. In order to make things more difficult for us crackers, the protectionists have devised many counter-strategies, the more obvious ones being: - keeping the various part of the store/compare/hide routines well apart in code (no match for zen-cracking); - filling these routines with "bogus" compares, bogus jumps and bogus variables, in order to make things more difficult for the crack (no match for decent crackers); - disseminating the code with anti-debugger tricks, like INT_3 instructions or jumps in and out protected mode (no match for our beloved [Soft-Ice]); - trying to eliminate the need for passwords altogether letting the user input "one letter" or "one number" or "one image" as answer to some variable question. In this lesson I'll teach you how to crack these "passletters" protection techniques. Let's first resume the "uses" of a password protection: PASSWORDS AS PERMISSION TO ACCESS These passwords serve to acknowledge that a legitimate user is using the program. This is the type of password that you'll find, for example, protecting your user account on Compuserve, on Networks or even in ATM machines used by banks or corporations. These require a little hardwiring to crack: ATM passnumber protection schemes rely on an answer from the central computer (they do NOT verify only the three magnetic areas in the magnetic strip on the card). The lines between ATM's & their hosts are usually 'weak' in the sense that the information transmitted on them is generally not encrypted in any way. (Some banks use encrypted information, but this is fairly easy to crack too). So for ATMs you should do the following 1) cross over the dedicated line between the ATM and the host; 2) insert your computer between the ATM and the host; 3) Listen to the "normal" messages and DO NOT INTERFERE YET; 4) Try out some operations with a legal card, make some mistakes, take note of the various codes; 5) When you are ready insert a fraudulent card into the ATM. Now the following happens: - the ATM sends a signal to the host, saying "Hey! Can I give this guy money, or is he broke, or is this funny card invalid?"; - the microcomputer intercepts the signal from the host, discards it, sends on the "there's no one using the ATM" signal; - the host gets the "no one using" signal and sends back its "good, keep watching out if somebody comes by, and for God's sake don't spit out any money on the street!" signal to the ATM; - the microcomputer intercepts this signal (again), throws it away (again), and sends the "Wow! That guy is like TOO rich! Give him as much money as he wants. In fact, he's so loaded, give him ALL the cash we have! He is a really valued customer." signal. - the ATM obediently dispenses cash till the cows come home. All this should be possible, but as a matter of fact it has not much to do with cracking, unless there is a special software protection on the line... so if you want to work on ATMs contact our fellow phreakers/hackers and learn their trade... and please remember to hack only cash dispenser that DO NOT HAVE a control camera :=) PASSWORDS AS REGISTRATION This type of password is often used in shareware programs. When you register the shareware program, you are sent a password that you use to upgrade your shareware program to a complete and more powerful version. This method, used frequently for commercial applications, has recently been used quite a lot by many windows applications that come "crippled" on the magazines cover CD-roms, requiring you to telephone a hot line (and paying) in order to get the "unique key" to unlock the "special protection". It's all bullshit: we'll learn in the "how to crack windows" lessons how easy it is to disable the various routines that verify your entry. PASSWORDS AS COPY PROTECTIONS This type of password is often used for games and entertainment software. The password query does not usually appear any more at the start of the program, or as the program is loading. Instead, the password query appears after one or more levels are completed (this innovation was pioneered by "EOB I" and the "Ultima" series) or when the user reloads a saved game or session. DONGLE PASSWORDS A few extremely expensive programs use a dongle (also called an hardware key). A dongle is a small hardware device containing a password or checksum which plugs into either a parallel or a serial port. Some specially designed dongles even include complete program routines. Dongles can be cracked, but the amount of work involved is considerable and the trial and error procedure currently used to crack them via software is extremely tedious. It took me more than a week to crack MULTITERM, Luxembourger dongle protected program. The quickest method to crack dongle protected programs, involves the use of pretty complicated hardware devices that cannot be dealt with here. I myself have only seldom seen them, and do not like at all to crack dongles via software, coz it requires a huge amount of zen thinking and of luck and of time. If you want more information on the hardware way to crack dongles, try to contact the older ones on the appropriate web sites, they may even answer you if you are nice, humble and really technically interested. The obvious principle, that applies to the software password types mentioned above is the following: The better the password is hidden, and the better it is encrypted, the more secure the program will be. The password may be - encrypted and/or - in a hooked vector and/or - in an external file and/or - in a SMC (Self modifying code) part Let's finally inspect the common "ready_made" protection schemes (used by many programmers that do not program themselves): * password read in * letters added to a key to be entered * complement of the letters formed xoring with 255 * saved key (1 char) * saved password (256 chars) * saved checksum (1 char), as protection, against simple manipulations * generating file PASSWORD.DAT with password, to be inserted inside a different file than the one containing the calling routine Now the lazy programmer that wants to "protect" his program searches first the file where the password is stored, then loads the key, the password and the checksum. He uses a decrypt procedure to decrypt the password and a check_checksum procedure to check whether the password was modified. All this is obviously crackabe in few seconds. [PASSWORD ACCESS INSIDE THE SETUP] Some computers have a password protected access INSIDE the Setup (at the beginning), the protection scheme does not allow a boot with a floppy and does not allow a setup modify. In these cases the only possible crack is an old hack method: * open the PC * find on the motherboard a small jumper (bridge) with the words "Pw" * take it away * PC on * run the setup with F1 or Del (depending from the BIOS) (the protection will not work any more) * deactivate inside the setup the option password * PC off * put the small jumper (bridge) back again * close the PC * PC on, cracked (if you want to be nasty you could now use the setup to set YOUR password) If you want to know more about access refuse and access denying, encryption and locking of the FAT tables, get from the web, and study, the (very well written) code of a virus called "Monkey", that does exactly this kind of devastation. Virus studying is, in general, very useful for cracking purposes, coz the virus'code is at times - very well written (pure, tight assembly) - using concealing techniques not much different from the protection schemes (often far superior) - using the most recent and best SMC (self modifying code) tricks But, and this is very important, do not believe that the protection schemes are very complicated! Most of the time the protection used are incredibly ordinary: as a final example of our paper protection schemes, let's take a program released not long ago (1994), but with a ridiculous protection scheme: TOP (Tiger on the prowl) a simulation from HPS. Here the cracking is straightforward: - MAP(memory_usage) and find main_sector - type "AAAA" as password - (s)earch main_sector:0 lffff "AAAA" - dump L80 "AAAA" location -40 (gives you a "wide" dump), this gives you already the "echo" of the correct password - breakpoint on memory read & write to "AAAA" location and backtrace the complete main_sector it's done! Here the code_lines that do protect TOP: 8A841C12 MOV AL,[SI+121C] move in AL first user letter 3A840812 CMP AL,[SI+1208] compare with echo 7402 JZ go_ahead_nice_buyer EB13 JMP beggar_off_ugly_cracker Now let's quickly crack it: ------------------------------------------------ CRACKING TOP.EXE (by +ORC, January 1996) ren top.exe top.ded symdeb top.ded - s (cs+0000):0 Lffff 8A 84 1C 12 3A 84 xxxx:yyyy (this is the answer of the debugger) - e xxxx:yyyy+2 08 (instead of 1C) - w - q ren top.ded top.exe ------------------------------------------------- And you changed the MOV AL, [SI+121C] instruction in a MOV AL, [SI+1208] instruction... it is now reading the ECHO instead of the characters you typed in... no wonder that the ECHO does compare exactly with itself... and you pass! "SOMETHING FISHY UNDER COVERS" Back to the "Passletter" type of password protected programs. Let's take as an example the protection used in a game of 1990: "F19", where the protection scheme asks you to identify a particular plane's silhouette. This kind of protection is used in order to avoid the use of memory locations where the passwords are stored: we saw in the first part of our "passwords hands on" how easy it is to crack those schemes. To crack this kind of protection, you could try a technique know as "memory snuffing". The protected program, START.EXE, install itself first at location xxxx:0000 with a length of 6C62 bytes, but proceeds to a relocation of its modules (with some SMC, self modifying code parts) in different locations. What does all this mean? Well, this could mean quite many things... the most important one for crackers is that the protection code will probably snap way ahead of the actual user input phase. Now you 'll quickly find out that the routine determining (randomly) which plane is being chosen, leaves the progressive number of this plane in one memory location: (imc) 43CD:DADA. This brings us to the random triggering mechanism: E87FAF CALL random_seed 83C402 ADD SP,02 8946E8 MOV [BP-18],AX and ds:(BP-18) is the location you are looking for Now, every time this random triggers, you get a different number (00-x14) in this location, corresponding to the different plane the user should choose. The random seed routine, evidently, comes back with the random seed in AX... what we now need is to zero it: the user will always have to choose the same plane: "plane 0", and he will have given the correct answer. Note how elegant all this is: we do not need to interfere with the whole mouse pointing routines, nor with the actual choosing of the planes... the random seed may choose whatever plane it wishes... the memory location for this choice will always report the (legitimate) choice of zero. So, let's quickly crack this program: --------------------------------------------------- CRACKING "F19" [START.EXE] (by +ORC, January 1996) ren start.exe start.ded <- let's have a dead file symdeb start.ded <- let's debug it - s cs:O lffff 83 C4 02 89 46 E8 <- search ADD SP,02 xxxx:yyyy <- debugger's answer - e xxxx:yyyy 58 [SPACE] 31 [SPACE] C0 [SPACE] - w <- write the crack - q <- back to the OS ren start.ded start.exe <- re-write the exe ---------------------------------------------------- You just transformed the instruction you searched for 83C402 ADD SP,+02 in the following sequence: 58 POP AX <- respecting ADD SP,+02 31C0 XOR AX,AX <- xoring to zero (the POP AX instruction increments the stack pointer by 2, in order to respect the previous ADD SP,+02). Well, nice. It's getting easier, isnt'it? Now let's take as example a protection that has no "echo" in memory. (At the beginning this was a smart idea: "the cracker won't find the correct password, 'coz it's not there, ah!". We'll now therefore crack one of the first programs that used this scheme: [Populous.exe], from Bullfrog. [POPULOUS.EXE] A old example of the protection scheme "password that is not a password" can be found in [Populous.exe], from Bullfrog. It's a very widespread program, and you'll surely be able to find a copy of it in order to follow this lesson. The program asks for the identification of a particular "shield", a combination of letters of various length: the memory location were the user password is stored is easily found, but there is (apparently) no "echo" of the correct password. You should be able, by now, to find by yourself the memory location were the user password is stored. Set a breakpoint memory read & write on this area, and you 'll soon come to the following section of code: F7AE4EFF IMUL WORD PTR [BP+FF4E] <- IMUL with magic_N° 40 INC AX 3B460C CMP AX, [BP+0C] 7509 JNZ beggar_off_ugly_copier 8B460C MOV AX, [BP+0C] A3822A MOV [2A82], AX E930FE JMP nice_buyer 817E0C7017CMP WORD PTR[BP+0C],1770 <- beggar_off I don't think that you need much more now... how do you prefer to crack this protection scheme? Would you choose to insert a MOV [BP+0C], AX and three NOPS (=6 bytes) after the IMUL instruction? Wouldn't you rather prefer the more elegant JMP to nice_buyer instruction at the place of the JNZ beggar_off? This solution has less nops: remember that newer protection schemes smell NOPs_patches!). Yeah, let's do it this way: --------------------------------------------------- CRACKING [Populous.exe] (by +ORC, January 1996) ren populous.exe populous.ded <- let's have a dead file symdeb populous.ded <- let's debug it - s cs:O lffff F7 AE 4E FF <- the imul magic_N° xxxx:yyyy <- debugger's answer - e xxxx:yyyy+4 EB [SPACE] 03 <- JMP anyway - w <- modify ded - q <- back to the OS ren populous.ded populous.exe <- let's re-have the exe ---------------------------------------------------- This time was easy, wasnt'it? Now you are almost ready with this course... let's crack a last application, a memory utility that is very widespread, very good (the programmers at Clockwork software are Codemasters), very useful for our purposes (you'll use it later to crack a lot of TSR) and, unfortunately for Clockworkers, very easy to crack at the level you are now. But, Hey! Do not forget that you would have never done it without this tutorial, so do the following: look toward east from your window, sip a Martini-Wodka (Two blocks of ice first, 1/3 dry Martini from Martini & Rossi, 1/3 Moskovskaia Wodka, 1/3 Schweppes indian tonic) and say three times: Thank-you +ORC!. [MAP.EXE] Let's now go over to one of the best TOOLS for mapping your memory usage that exist: MAP.EXE (version 2) from the masters at Clockwork software. The usage of this tool has been recommended in Lesson 2, and you should learn how to crack it, coz it comes with an annoying nag-screen ("Nigel" screen). In [Map.exe] this ubiquitous "Nigel" screen appears at random waiting for a random amount of time before asking the user to press a key which varies every time and is also selected at random. The use of a single letter -mostly encrypted with some XOR or SHR- as "password" makes the individuation of the relevant locations using "snap compares" of memory much more difficult. But the crack technique is here pretty straightforward: just break in and have a good look around you. The INT_16 routine for keyboard reading is called just after the loading of the nag screen. You 'll quickly find the relative LODSB routine inside a routine that paints on screen the word "Press" and a box-edge after a given time delay: B95000 MOV CX,0050 2EFF366601 PUSH CS:[0166] 07 POP ES AC LODSB ... You could already eliminate the delay and you could already force always the same passletter, in order to temperate the effects of the protection... but we crack deep!: let's do the job and track back the caller! The previous routine is called from the following section of the code: 91 XCHG AX,CX 6792 XCHG AX,DX 28939193 SUB [BP+DI+9391],DL 2394AA94 AND DX,[SI+94AA] 2EC7064B880100 MOV WORD PTR CS:[884B],0001 2E803E5C0106 CMP BYTE PTR CS:[015C],06 7416 JZ ret <- Ha! jumping PUSHa & POPa! 505351525756 PUSH the lot E882F3 CALL 8870 2E3B064B88 CMP AX,CS:[884B] 7307 JAE after RET <- Ha! Not taking the RET! 5E5F5A595B58 POP the lot C3 RET ... <- some more instructions E86700 CALL delay_user BE9195 MOV SI,9591 2E8B3E255C MOV DI,CS:[5C25] 83EF16 SUB DI,+16 2E8A263D01 MOV AH,CS:[013D] 50 PUSH AH E892C7 CALL routine_LODSB <-- HERE! B42C MOV AH,2C CD21 INT 21 <- get seconds in DH 80E60F AND DH,0F 80C641 ADD DH,41 58 POP AX 8AC6 MOV AL,DH 83EF04 SUB DI,+4 AB STOSW E85A00 CALL INT_16_AH=01 B400 MOV AH,00 CD16 INT 16 24DF AND AL,DF <- code user's letter_answer 3AC6 CMP AL,DH <- pass_compare 75F3 JNZ CALL INT_16_AH=01 E807F3 go_ahead You just need to look at these instructions to feel it: I think that unnecessary code segments (in this case protections) are somehow like little snakes moving under a cover: you cannot easily say what's exactly going on yet, but you could bet that there is something fishy going on. Look at the code preceding your LODSB routine call: you find two JUMPS there: a JZ ret, that leaves a lot of pusha and popa aside, and a JAE after RET, that does not take the previous ret. If you did smell something here you are thoroughly right: The first JZ triggers the NIGEL screen protection, and the second JAE does THE SAME THING (as usual, there are always redundances, exactly as there are a lot of possibilities to disable a single protection). Now you know... you can disable this protection at different points: the two easiest blueprints being 1) to change 7416 (JZ ret) in a EB16 (JMP ret anyway) 2) to change 7307 (JAE after ret) in a 7306 (JAE ret). We have not terminated yet: if you try locating this part of the code in order to change it, you won't have any luck: it's a SMC (Self modifying code) part: it is loaded -partly- from other sections of the code (here without any encryption). You must therefore first of all set a breakpoint on memory range; find out the LODSW routine; find out the real area; dump that memory region; find out a search sequence for the "dead" code... and finally modify the "dead" program. Now let's quickly crack it: ------------------------------------------------ CRACKING MEM.EXE (version 2) (by +ORC, January 1996) ren map.exe map.ded symdeb map.ded - s (cs+0000):0 Lffff 74 16 50 53 51 52 57 xxxx:yyyy <- this is the debugger's answer - e xxxx:yyyy EB - w - q ren map.ded map.exe ------------------------------------------------- Now you have done it, NIGEL has been cracked! Well, that's it for this lesson, reader. Not all lessons of my tutorial are on the Web. You 'll obtain the missing lessons IF AND ONLY IF you mail me back (via anon.penet.fi) with some tricks of the trade I may not know that YOU discovered. Mostly I'll actually know them already, but if they are really new you'll be given full credit, and even if they are not, should I judge that you "rediscovered" them with your work, or that you actually did good work on them, I'll send you the remaining lessons nevertheless. Your suggestions and critics on the whole crap I wrote are also welcomed. E-mail +ORC +ORC an526164@anon.penet.fi HOW TO CRACK, by +ORC, A TUTORIAL --------------------------------------------------------------------------- Lesson 5.1: Disk & CD-Rom access (basics) --------------------------------------------------------------------------- [MARIO ANDRETTI] [REACH FOR THE SKY] [FS v.2.12] -------------------------------------- LESSON 5 (1) - HOW TO CRACK, HANDS ON - Disk/CDROM access (plus bypasses "on the fly") Somewhere I have to put the bypasses (loader programs) in this tutorial, allow me to put them here: Preparing a loader to bypass a protection [MARIO ANDRETTI] At time the protectionists hook vectors in order to impose a particular protection. In this (and similar) cases a good crack-way is to prepare a "loader" program, that "de-hooks" the vector used for the protection. This kind of crack can be used also for internet cracking (on some firewall configurations, see lesson A.2). As example let's take "Mario andretti racing challenge", a stupid game that uses the SAME (!) protection scheme you'll still find to day on some access routines of military servers around the witlessly called "free" world. In order to crack this cram you would prepare a loader on the following lines: loc code instruction what's going on ------------------------------------------------------- :0100 EB44 JMP 0146 ... :0142 0000 <- storing for offset of INT_21 :0144 5887 <- storing for segment of INT_21 :0146 FA CLI :0147 0E PUSH CS :0148 1F POP DS :0149 BCB403 MOV SP,03B4 :014C FB STI :014D 8C1EA901 MOV [01A9],DS <- save DS :0151 8C1EAD01 MOV [01AD],DS three :0155 8C1EB101 MOV [01B1],DS times :0159 B82135 MOV AX,3521 <- get INT_21 :015C CD21 INT 21 in ES:BX :015E 891E4201 MOV [0142],BX <- store offset :0162 8C064401 MOV [0144],ES <- store segment :0166 BA0201 MOV DX,0102 :0169 B82125 MOV AX,2521 <- set INT_21 to :016C CD21 INT 21 DS:0102 :016E 0E PUSH CS :016F 07 POP ES <- ES= current CS :0170 BBB403 MOV BX,03B4 :0173 83C30F ADD BX,+0F :0176 B104 MOV CL,04 :0178 D3EB SHR BX,CL <- BX= 3C :017A B8004A MOV AX,4A00 <- Modify memory block :017D CD21 INT 21 to 3C paragraphs :017F BA9E01 MOV DX,019E <- ds:dx=program name :0182 BBA501 MOV BX,01A5 <- es:bx = param. block :0185 B8004B MOV AX,4B00 <- load ma.com :0188 CD21 INT 21 :018A 2E8B164201 MOV DX,CS:[0142] <- reset old int_21 :018F 2E8E1E4401 MOV DS,CS:[0144] :0194 B82125 MOV AX,2521 :0197 CD21 INT 21 :0199 B8004C MOV AX,4C00 <- terminate with return :019C CD21 INT 21 code :019E 6D612E636F6D00 "ma.com" 0000 fence :01A7 B2015887 :01AB B2015887 :O1AF B2015887 0000 fence let's now prepare a routine that hooks INT_21: push all CMP AX,2500 <- go on if INT_21 service 25 JNZ ret CMP Word Ptr [0065], C00B <- go on if location 65 = C00B JNZ ret MOV Byte Ptr [0060], EB <- crack instructions MOV Byte Ptr [0061], 3C MOV Byte Ptr [0062], 40 <- INC AX MOV Byte Ptr [0063], 90 <- NOP MOV Byte Ptr [0064], 48 <- DEC AX pop all JMP FAR CS:[0142] <- JMP previous INT_21 From now on this loader will work every time that a program with location [0065] containing an 0R AX,AX instruction (0BC0: it's the case of ma.com) calls INT_21 service 25 (hook a vector), the target program will be modified on the fly and will get, at location [0060], the instruction JMP 3C locations ahead, despite the fact that it has routines capable of self checking in order to make sure it has not been modified. The most important thing is the routine that YOU write that will precede the call to INT_21 (or any other INT) service 25 (or any other service) in order to crack on the fly the offending program. I'll show you another one, this one for [Reach for the skies] (reach.com): push all CMP AH,3D <- is it service 3D? (open file) JNZ ret <- no, so ret CMP DX,13CE <- you wanna open file at 13CE? JNZ ret <- no, so ret MOV AX,[BP+04] <- in this case MOV DS,AX CMP Byte Ptr [B6DA],74 <- old instructions JNZ 015B CMP Byte Ptr [B6DB],0F <- ditto JNZ 015B CMP Byte Ptr [B6DC],80 <- ditto, now we now where we are JNZ 015B MOV Byte Ptr [B6DA],EB <- crack MOV Byte Ptr [B697],40 <- camouflaged no-opping MOV Byte Ptr [B698],48 <- cam nop MOV Byte Ptr [B699],90 <- cam nop MOV Byte Ptr [B69A],40 <- cam nop MOV Byte Ptr [B69B],48 <- cam nop MOV DX,CS:[0165] MOV DS,CS:[0167] MOV AX,2521 <- set hook INT 21 POP all JMP FAR CS:[0165] Here you did change the instruction 740F in the instruction EB0F, and you did "noop" the instructions at B697-B69B. (Well, more elegantly than "noop" them with "90" bytes, you choose a INC AX, DEC AX, NOP, INC AX, DEC AX sequence instead! There are sound reasons to use a sequence of "working" instructions instead of NOPs: recent protection schemes "smell" patched nops inside the program and trash everything if they find more than -say- three consecutive NOPs! You should always try to choose THE LESS INTRUSIVE and MORE "CAMOUFLAGED" solution when you crack!) You can apply this kind of crack, on the same lines, to many programs that perform self checking of the code and hook the vectors. REAL DISK ACCESS STUFF Now we may come to the subject of this lesson: As usual, let's begin from the beginning: history is always the key that allows an understanding of present and future, in cracking matters too. As the older 5 1/4 inch big black floppy disks were still used (the 320K/8 tracks or 360K/9 tracks ones, that were really "floppy" and have nowadays almost disappeared) one of the more common methods to protect a program, was to format the "master" (key) disk in a weird way. Old floppy disk for the PC did usually store 360K at 9 sectors per track. Some basics for those of you that do not know anything: in order to defeat this kind of cracks you need to know two things: the floppy disk parameter block (FDPB) and the interrupt routines dealing with format/read disk (basically INT_13). Most often, the protection scheme is to either format one or more sectors or tracks with sector sizes other than the standard 512 bytes, or to either give one of the sectors a wild sector number like 211 or just not format a whole track of eight/nine/15 sectors. If you, for instance, have got the same (very old) copy of VisiCalc master I do, you'll find that sector 8 on track 39 is missing entirely. The interrogation with assembly or with an "ad hoc" utility (I use the tools I wrote myself, but you 'll be able to find many such utilities in public domain, the oldest one, from 1984 (!) being the seasoned [U-ZAP] an "Ultra utility" from the "Freesoft company") will tell you which sector numbers were altered, their size in bytes, and if they were formatted with a CRC error (another not so fancy trick). The floppy disk parameters are stored in the BIOS: interrupt vector 1E contains the address of the floppy disk parameter block. The FDPB's contents are the following: Offset Function crackworthy? Example 0 Step rate & head unload no DF 1 head load time no 02 2 Motor on delay no 25 3 Number of bytes per sector yes 02 4 Last sector number yes 12 5 Gap length yes 1B 6 Data track length yes FF 7 Format gap length yes 54 8 Format byte no F6 9 Head settle time no 0F A Motor start time no 02 0) Offset #0: the left "nybble" (single digit) of this value is the step rate time for the disk drive head. The right nybble is the disk head unload time. These values are best left alone. 1) Offset #1: again, don't fool around with these values. The left nybble is the disk head load time, and the right nybble is the direct memory access mode select. 2) Wait time until motor is turned off. Not normally of use. 3) Bytes-per-sector value: AH-HAH! If you place a "0" in this value, the PC expects all sectors to be 128 bytes long. A "1" means a sector size of 256 bytes, a "2" means 512 bytes (this is the standard DOS value), and a "3" means 1024 bytes per sector. 4) Highest sector number on a track: this is used for formatting and tells DOS how many sectors there are on each track. 5) Gap length for diskette reads: this is what you fool around with if you keep getting CRC errors when you try to read a non-standard size sector. Normally, you can just leave this alone except when formatting with a U-Format tool. 6) Data length: This contains the number of bytes in a sector when the value in table byte #4 doesn't contain a 0, 1, 2, or 3. 7) Number of bytes in the gap between sectors: this is also only used when formatting special tracks. 8) Format fill byte: When formatting, this is the initialization byte that will be placed in all new sectors. 9) Head settle time: leave this alone. A) Motor start time: don't fool with this either. In order to modify globally the number of tracks on a given disk and the number of sectors per track you can always format with the DOS command switches "/t:" and "/n:" FORMAT /t:tracks /n:sectors If you want to find out what the existing parameters are, run [Debug.exe] or [Symdeb.exe] and enter the following commands: - d 0:78 l 4 <- get FDPB address 0000:0070 22 05 00 <- debugger's likely response - d 0:522 l a <- get 10 FDPB values 0000:520 DF 02 25 02 12 1B FF... <- see preceding table Remember that all standard disk formats under DOS support a sector size of 512 bytes, therefore, for one-sided 5.25 inch floppies: 40t*8s*512b=163.840 bytes (160Kb) 40t*9s*512b=184.320 bytes (180Kb) and for two-sided 5.25 inch floppies: 40t*8s*512b*2sides=327.680 bytes (320Kb) 40t*9s*512b*2sides=368.640 bytes (360Kb) Beginning with DOS version 3.0 (Yeah, more and more history!) a new floppy disk format has been supported: The IBM AT (80286 CPU) introduced the so called "high capacity" 5.25 u- inch floppy, capable of storing 1.2M at 15 sectors per track: 80t*15s*512b*2sides=1.228.800 bytes (1.2Mb) Later on were introduced the to-day universally used 3.5 inch floppies, the ones inside a rigid small plastic cartridge, and we have, similarly: 3.5-inch double sided/double density 720K 3.5-inch double sided/quad density (HD) 1440K 3.5-inch double sided/high density 2880K [INT_13, AH=18, Set media type for format] In order to create weird layouts, the protectionists use interrupt 13h, service 18h, that specifies to the formatting routines the number of tracks and sectors per track to be placed on the media: * Registers on entry: AH=18h; CH=N° of tracks; CL= Sectors per track; DL= Drive number (A=0; B=1;C=2... bit 7 is set if the drive is an hard disk) * Registers on Return: DI: Offset address of 11-byte parameter table; ES: Segment address of 11-byte parameter table. [INT_13, AH=2, Read disk sectors] In order to read them, they have to use INT_13, service 2, read disk sectors, with following layout: * Registers on entry: AH=2h; AL= N° of sectors; BX= Offset address of data buffer; CH=track; CL= Sector; DH= Head (side) number; DL= Drive number; ES: Segment address of data buffer. * Registers on Return: AH= return code. If the carry flag is not set, AH=0, therefore the weird sector has been read, if on the contrary the carry flag is set, AH reports the status byte as follows: 76543210 HEX DEC Meaning 1 80h 128 Time out - drive crazy 1 40h 064 Seek failure, could not move to track 1 20h 032 Controller kaputt 1 10h 016 Bad CRC on disk read 1 09h 009 DMA error - 64K boundary crossed 1 08h 008 DMA overrun 1 04h 004 Bad sector - sector not found 11 03h 003 Write protect! 1 02h 002 Bad sector ID (address mark 1 01h 001 Bad command [Return code AH=9: DMA boundary error] One of the possible errors should be explained, coz it is used in some protection schemes: AH=9 DMA boundary error, means that an illegal boundary was crossed when the in formation was placed into RAM. DMA (Direct memory access) is used by the disk service routines to place information into RAM. If a memory offset address ending in three zeros (ES:1000, ES: 2000...) falls in the middle of the area being overlaid by a sector, this error will occur. [INT_13, AH=4 Verify disk sectors] Another possible protection interrupt is interrupt 13H, service 4, Verify disk sectors. Disk verification takes place on the disk and DOES NOT involve verification of the data on the disk against data in memory! This function has no buffer specification, does not read or write a disk: it causes the system to read the data in the designated sector or sectors and to check its computed cyclic redundancy check (CRC) against data stored on the disk. See INT_13, AH=2 registers and error report. [CRC] The CRC is a checksum, that detects general errors. When a sector is written to disk, an original CRC is calculated AND WRITTEN ALONG with the sector data. The verification service reads the sector, recalculates the CRC, and compares the recalculated CRC with the original CRC. We saw that some protection schemes attempt to disguise interrupt calls. This is particularly frequent in the disk access protection schemes that utilize INT_13 (the "disk" interrupt). If you are attempting to crack such programs, the usual course of action is to search for occurrences of "CD13", which is machine language for interrupt 13. One way or another, the protection scheme has to use this interrupt to check for the special sectors of the disk. If you examine a cross section of the program, however, you'll find programs which do not have "CD13" in their machine code, but which clearly are checking the key disk for weird sectors. How comez? There are several techniques which can be used to camouflage the protection scheme from our nice prying eyes. I'll describe here the three such techniques that are more frequent: 1) The following section of code is equivalent to issuing an INT 13 command to read one sector from drive A, side 0, track 29h, sector ffh, and then checking for a status code of 10h: cs:1000 MOV AH,02 ;read operation cs:1002 MOV AL,01 ;1 sector to read cs:1004 MOV CH,29 ;track 29h cs:1006 MOV CL,FF ;sector ffh cs:1008 MOV DX,0000 ;side 0, drive A cs:100B XOR BX,BX ;move 0... cs:100D MOV DS,BX ;...to DS register cs:100F PUSHF ;pusha flags cs:1010 PUSH CS ;pusha CX cs:1011 CALL 1100 ;push address for next instruction onto stack and branch cs:1014 COMP AH,10 ;check CRC error cs:1017 ... rest of verification code ... ... cs:1100 PUSHF ;pusha flags cs:1101 MOV BX,004C ;address of INT_13 vector cs:1104 PUSH [BX+02] ;push CS of INT_13 routine cs:1107 PUSH [BX] ;push IP of INT_13 routine cs:1109 IRET ;pop IP,CS and flags Notice that there is no INT 13 command in the source code, so if you had simply used a debugger to search for "CD13" in the machine code, you would never have found the protection routine. 2) Another technique is to put in a substitute interrupt instruction, such as INT 10, which looks harmless enough, and have the program change the "10" to "13 (and then back to "10") on the fly. A search for "CD13" would turn up nothing. 3) The best camouflage method for interrupts I have ever cracked (albeit not on a INT 13) was a jump to a section of the PROGRAM code that reproduces in extenso the interrupt code. This elegant (if a little overbloated) disguise mocks every call to the replicated interrupt. LOADING ABSOLUTE DISK SECTORS Old good [debug.com] has been called the "swiss army knife" of the cracker. It allows a lot of nice things, inter alia the loading, reading, modifying and writing of absolute sectors of the disks. The sector count starts with the first sector of track 0, next sector is track 0, second side (if double sided), then, back to the first side, track 1, and so on, until the end of the disk. Up to 80h (128) sectors can be loaded at one time. To use you must specify starting address, drive (0=A, 1=B, etc...), starting sector and number of sectors to load. - l 100 0 10 20 This instruction tells DEBUG to load, starting at DS:0100, from drive A, sector 10h for 20h sectors. This allows at times the retrieval of hidden and/or weird formatted data. If you get an error, check the memory location for that data. Often times, part of the data has been transferred before the error occurs, and the remainder can be manually entered or gathered through repetitive retries. Bear all this in mind learning the following cracks. Let's now crack an "oldie" primitive: MS Flight simulator (old version 2.12, from 1985!) This old program used -in 1985!- following beautiful protection scheme: on the disk you had only a "stub", called FS.COM with few bytes, which had following instructions: loc code instruction what's going on ------------------------------------------------------- :0100 FA CLI ;why not? :0101 33C0 XOR AX,AX ;ax=0 :0103 8ED0 MOV SS,AX ;ss=0 :0105 BCB0C0 MOV SP,C0B0 ;SP=C0B0 :0108 8EC0 MOV ES,AX ;ES=0 :010A 26C70678003001 MOV Wptr ES:[0078],0130 ;Wp 0:78=130 :0111 268C0E7A00 MOV ES:[007A],CS ;0:7A=Segment :0116 BB0010 MOV BX,1000 ;BX=1000 :0119 8EC3 MOV ES,BX ;ES=1000 :011B 33DB XOR BX,BX ;BX=0 :011D B80102 MOV AX,0201 ;AH=2 AL=1 sector :0120 BA0000 MOV DX,0000 ;head=0 drive=0 :0123 B96501 MOV CX,0165 ;track=1 sector=65 (!) :0126 CD13 INT 13 ;INT 13/AH=2 :0128 B83412 MOV AX,1234 ;AX=1234 :012B EA00000010 JMP 1000:0000 ;JMP to data we just read :0130 CF IRET ;Pavlovian, useless ret You see what's happening in this old protection scheme, don't you? Herein you can watch the same snap that happens in more recent (much more recent) protection schemes (as you'll see in the next lesson): the protection searches for a weird formatted sector and/or for particular data. That should be no problem for you any more: you should just reverse engineer everything (and that goes on pretty quickly: just watch and break on the INT_13 calls), fetch the "weird" data, tamper the whole crap and have your soup as you like it. One more word about "old" protection schemes. Be careful not to spurn them! Some of them are -- CLEVER -- STILL USED -- DIFFICULT TO CRACK... I mean, this older DOS programs had nice protections... it's pretty annoying to crack windows programs that require a registration number: as you saw in Lesson 3, you just type your name and a serial number of your choice in, say "666666666", break into the program with WINICE, search the "666666666" and search too, for good measure, your own name, set a memory read breakpoint where the number dwells and look at the code that manipulates your input. As [Chris] rightly pointed out, you can even rip the code straight out of the program and create a key generator which will produce a valid code. This code will work for any name you typed in only in the "pure maths manipulation" protection schemes, and will on the contrary be specific, following the name you typed in, the "alpha-maths manipulation" protection schemes (like MOD4WIN, see the Windows lessons), watch in this case the "pseudo-random xoring" of the letters that compose your name. -- STUNNING, coz new ideas have always been infrequent, and they are getting more and more rare in this objectionable world of lazy, incapable programmers patronizing us with ill-cooked outrages like Windows'95... yeah, as usual there is no "development" at all, quite the contrary, I would say. Take a step backward, sip a good Martini-Wodka (please remember that only Ice cubes, Dry Martini, Wodka Moskovskaja, Schweppes' "Indian tonic" a green olive from Tuskany and a maltese lemon zest will really be perfect) and watch from your balcony, with unsullied eyes, your town and the people around you: slaves everywhere, leaving home at 7.30 in the morning, stinking in a progression of identical cars, forced to interminably watch advertisement panels and endlessly listen to boorish publicity, happy to go to work (if they happen to have the "luck" to work, in this inequitable society) the whole day long in order to produce other cars in order to buy, one day, a new car with a different colour... Why people don't look at the stars, love each other, feel the winds, ban the stinking cars from the places where they live and eat, study colours... name yourself a not-consumistic activity? Why don't they read any poems any more? No poetry any more, in the grey society of the publicity-spots slaves...poetry will soon be forbidden, coz you cannot CONSUME as you read poems, and in this farce of a society you are BOUND to consume, that's the only thing they want you to do... you are CULTIVATED to consume... no books worth to read any more... stupid american conventional cram everywhere... boy, at times I'm missing some well placed neutron bombs, the ones that would kill all these useless zombies and leave noble books and good Wodka untouched. It's difficult to believe in democracy any more... if I ever did... all the useless zombie do -unfortunately- vote, and they do vote for "smiling semblances", for "conventionally minded idiots" that so act as if they would "really" be like what they "look" like and could not care less about anything else than making bucks and defend intolerant and petty patterns. The slaves choose the people they have "seen" on TV... as if the egyptians would VOTE for their pharaohs, exhilarated under the whips of publicity... sorry, at times I forget that you are here for the cracks, and could not care less about what I think... You 'll obtain the OTHER missing lessons IF AND ONLY IF you mail me back (via anon.penet.fi) with some tricks of the trade I may not know that YOU discovered. Mostly I'll actually know them already, but if they are really new you'll be given full credit, and even if they are not, should I judge that you "rediscovered" them with your work, or that you actually did good work on them, I'll send you the remaining lessons nevertheless. Your suggestions and critics on the whole crap I wrote are also welcomed. E-mail +ORC +ORC an526164@anon.penet.fi HOW TO CRACK, by +ORC, A TUTORIAL --------------------------------------------------------------------------- Lesson 6.1: Funny tricks (1) --------------------------------------------------------------------------- LESSON 6 (1) - Funny tricks. Xoring, Junking, Sliding EXERCISE 01: [LARRY in search of the King] Before the next step let's resume what you have learned in the lessons 3-5, beginning with a very simple crack exercise (again, we'll use the protection scheme of a game, for the reasons explained in lesson 1): SEARCH FOR THE KING (Version 1.1.). This old "Larry" protection sequence, is a "paper protection" primitive. It's a very widespread (and therefore easy to find) program, and one of the first programs that instead of asking meaningful passwords (which offer us the possibility to immediately track them down in memory) asked for a random number that the good buyer could find on the manual, whereby the bad cracker could not. (Here you choose -with the mouse- one number out of 5 possible for a "gadget" choosen at random). I don't need any more to teach you how to find the relevant section of code (-> see lesson 3). Once you find the protection, this is what you get: :protection_loop :C922 8E0614A3 MOV ES,[A314] ... :C952 50 0E PUSH AX & CS :C954 E81BFF CALL C872 <- call protection scheme :C957 5B POP BX twice :C959 8B76FA MOV SI,[BP-06] <- prepare store_room :C95C D1E6 SHL SI,1 <- final prepare :C95E 8942FC MOV [BP+SI-04],AX <- store AX :C961 837EFA00 CMP Word Ptr [BP-06],+00 <- good_guy? :C965 75BB JNZ C922 <- loop, bad guy :C967 8E0614A3 MOV ES,[A314] :C96B 26F606BE3501 TEST Byte Ptr ES:[35BE],01 <- bad_guy? :C971 74AF JZ C922 <- loop, bad guy :C973 8B46FC MOV AX,[BP-04]... <- go on good guy Let's see now the protection scheme called from :C954 :C872 55 PUSH BP ... :C8F7 90 NOP :C8F8 0E PUSH CS :C8F9 E87234 CALL FD6E <- call user input :C8FC 5B POP BX :C8FD 5B POP BX :C8FE 8B5E06 MOV BX,[BP+06] :C901 D1E3 SHL BX,1 :C903 39872266 CMP [BX+6622],AX <- right answer? :C907 7505 JNZ C90E <- no, beggar_off :C909 B80100 MOV AX,0001 <- yes, AX=1 :C90C EB02 JMP C910 :C90E 2BC0 SUB AX,AX <- beggar_off with AX=0 :C910 8BE5 MOV SP,BP :C912 5D POP BP :C913 CB RETF <- back to main Here follow 5 questions, please answer all of them: 1) Where in memory (in which locations) are stored the "right" passnumbers? Where in memory is the SEGMENT of this locations stored? How does the scheme get the OFFSET? 2) Would setting NOPs instructions at :C965 and :C971 crack? Would it be a good idea? 3) Would changing :C907 to JZ crack? Would it be a good idea? 4) Would changing :C907 to JNZ C909 crack? Would it be a good idea? 5) Write down (and try) at least 7 OTHER different patches to crack this scheme in spades (without using any NOP!). Uff! By now you should be able to do the above 5 exercises in less than 15 minutes WITHOUT USING THE DEBUGGER! Just look at the data above and find the right answers feeling them... (you 'll now which one are the right one checking with your debugger... score as many points as you like for each correct answer and sip a good Martini-Wodka... do you know that the sequence should ALWAYS be 1) Ice cubes 2) Martini Dry 3) Wodka Moskovskaja 4) olive 5) lemon 6) Schweppes Indian tonic? Let's now come to the subject of this lesson: -----> [Xoring] (Simple encryption methods) One easy way to encrypt data is the XOR method. XOR is a bit manipulation instruction that can be used in order to cipher and decipher data with the same key: Byte to encrypt key result FF XOR A1 5E 5E XOR A1 FF As you can see XOR offers a very easy way to encrypt or to decrypt data, for instance using the following routine: encrypt_decrypt: mov bx, offset_where_encryption/decryption_starts xor_loop: mov ah, [bx] <- get current byte xor ah, encrypt_value <- engage/disengage xor mov [bx], ah <- back where you got it inc bx <- ahead one byte cmp bx, offset_start_+_size <- are we done? jle xor_loop <- no, then next cycle ret <- back where we came from The encrypt_value can be always the same (fixed) or chosen at random, for instance using INT_21, service 2Ch (get current time) and choosing as encrypt_value the value reported in DL (but remembering to discard the eventual value 0, coz otherwise it would not xor anything at all!) random_value: mov ah,2Ch int 21h cmp dl,0 je random_value mov encrypt_value,dl The problem with XORing (and with many other encryption methods), is that the part of the code that calls the encryption routine cannot be itself encrypted. You'll somewhere have, "in clear" the encryption key. The protectionist do at times their best to hide the decrypting routine, here are some common methods: -----> JUNK FILLING, SLIDING KEYS AND MUTATING DECRYPTORS These are the more common protection method for the small decryption part of the program code. This methods, originally devised to fool signature virus scanners, have been pinched from the polymorphic virus engines of our fellows viriwriters, and are still in use for many simple decryption protection schemes. For parts of the following many thanks go to the [Black Baron], it's a real pity that so many potential good crackers dedicate so much time to useless (and pretty repetitive) virus writing instead of helping in our work. This said, virus studying is VERY important for crackers coz the code of the viri is * ULTRAPROTECTED * TIGHT AND EFFECTIVE * CLOAKED AND CONCEALED. Let's show as example of the abovementioned protection tactics the following ultra-simple decryptor: MOV SI,jumbled_data ;Point to the jumbled data MOV CX,10 ;Ten bytes to decrypt mn_loop: XOR BYTE PTR [SI],44 ;XOR (un_scramble!) a byte INC SI ;Next byte LOOP mn_loop ;Loop the 9 other bytes This small program will XOR the ten bytes at the location pointed to by SI with the value 44. Providing the ten bytes were XORed with 44 prior to running this decryptor the ten bytes will be restored to their original state. In this very simple case the "key" is the value 44. But there are several tricks involving keys, the simplest one being the use of a "sliding" key: a key that will be increased, or decreased, or multiplied, or bit-shifted, or whatever, at every pass of the loop. A possible protection can also create a true "Polymorph" decryptor, a whole decryptor ROUTINE that looks completely different on each generation. The trick is to pepper totally random amounts of totally random instructions, including JUMPS and CALLS, that DO NOT AFFECT the registers that are used for the decryption. Also this kind of protection oft uses a different main decryptor (possibly from a selection of pre-coded ones) and oft alters on each generation also all the registers that the decryptor uses, invariably making sure that the JUNK code that it generates doesn't destroy any of the registers used by the real decryptor! So, with these rules in mind, here is our simple decryptor again: MOV DX,10 ;Real part of the decryptor! MOV SI,1234 ;junk AND AX,[SI+1234] ;junk CLD ;junk MOV DI,jumbled_data ;Real part of the decryptor! TEST [SI+1234],BL ;junk OR AL,CL ;junk mn_loop: ADD SI,SI ;junk instr, but real loop! XOR AX,1234 ;junk XOR BYTE PTR [DI],44 ;Real part of the decryptor! SUB SI,123 ;junk INC DI ;Real part of the decryptor! TEST DX,1234 ;junk AND AL,[BP+1234] ;junk DEC DX ;Real part of the decryptor! NOP ;junk XOR AX,DX ;junk SBB AX,[SI+1234] ;junk AND DX,DX ;Real part of the decryptor! JNZ mn_loop ;Real part of the decryptor! As you should be able to see, quite a mess! But still executable code. It is essential that any junk code generated by the Polymorph protection is executable, as it is going to be peppered throughout the decryptor. Note, in this example, that some of the junk instructions use registers that are actually used in the decryptor! This is fine, providing the values in these registers aren't destroyed. Also note, that now we have random registers and random instructions on each generation. So, a Polymorph protection Engine can be summed up into three major parts: 1 .. The random number generator. 2 .. The junk code generator. 3 .. The decryptor generator. There are other discrete parts but these three are the ones where most of the work goes on! How does it all work? Well a good protection would * choose a random selection of registers to use for the decryptor and leave the remaining registers as "junk" registers for the junk code generator. * choose one of the compressed pre-coded decryptors. * go into a loop generating the real decryptor, peppered with junk code. From the protectionist's point of view, the advantages of this kind of method are mainly: * the casual cracker will have to sweat to find the decryptor. * the casual cracker will not be able to prepare a "patch" for the lamers, unless he locates and patches the generators, (that may be compressed) coz otherwise the decryptor will vary every time. To defeat this kind of protection you need a little "zen" feeling and a moderate knowledge of assembler language... some of the junk instructions "feel" quite singular when you look at them (->see lesson B). Besides, you (now) know what may be going on and memory breakpoints will immediately trigger on decryption... the road is open and the rest is easy (->see lessons 3-5). -----> Starting point number magic For example, say the encrypted code started at address 10h, the following could be used to index this address: MOV SI,10h ;Start address MOV AL,[SI] ;Index from initial address But sometimes you'll instead find something like the following, again based on the encrypted code starting at address 10h: MOV DI,0BFAAh ;Indirect start address MOV AL,[DI+4066h) ;4066h + 0BFAAh = 10010h (and FFFF = 10h)!! The possible combinations are obviously infinite. [BIG KEYS] (Complicated encryption methods) Prime number factoring is the encryption used to protect sensible data and very expensive applications. Obviously for few digit keys the decoding is much easier than for, say, 129 or 250 digit keys. Nevertheless you can crack those huge encryption too, using distributed processing of quadratic sieve equations (which is far superior for cracking purpose to the sequential processing methods) in order to break the key into prime numbers. To teach you how to do this sort of "high" cracking is a little outside the scope of my tutorial: you'll have to write a specific short dedicated program, linking together more or less half a thousand PC for a couple of hours, for a 250 bit key, this kind of things have been done quite often on Internet, were you can also find many sites that do untangle the mysteries (and vagaries) of such techniques. As References I would advocate the works of Lai Xueejia, those swiss guys can crack *everything*. Begin with the following: Xuejia Lai, James Massey, Sean Murphy, "Markov Ciphers and Differential Cryptanalysis", Advances in Cryptology, Eurocrypt 1991. Xuejia Lai, "On the Design and Security of Block Ciphers", Institute for Signal and Information Processing, ETH-Zentrum, Zurich, Switzerland, 1992 Factoring and primality testing is obviously very important for this kind of crack. The most comprehensive work I know of is: (300 pages with lengthy bibliography!) W. Bosma & M. van der Hulst Primality Testing with Cyclotomy Thesis, University of Amsterdam Press. A very good old book you can incorporate in your probes to build very effective crack programs (not only for BBS accesses :=) is *the* "pomerance" catalog: Pomerance, Selfridge, & Wagstaff Jr. The pseudoprimes to 25*10^9 Math. Comp. Vol 35 1980 pp. 1003-1026 Anyway... make a good search with Lykos, and visit the relevant sites... if encryption really interests you, you'll be back in two or three (or thirty) years and you'll resume cracking with deeper erudite knowledge. [PATENTED PROTECTION SYSTEMS] The study of the patented enciphering methods is also *quite* interesting for our aims :=) Here are some interesting patents, if you want to walk these paths get the complete texts: [BEST] USPat 4168396 to Best discloses a microprocessor for executing enciphered programs. Computer programs which have been enciphered during manufacture to deter the execution of the programs in unauthorized computers, must be decrypted before execution. The disclosed microprocessor deciphers and executes an enciphered program one instruction at a time, instead of on a continuous basis, through a combination of substitutions, transpositions, and exclusive OR additions, in which the address of each instruction is combined with the instruction. Each unit may use a unique set of substitutions so that a program which can be executed on one microprocessor cannot be run on any other microprocessor. Further, Best cannot accommodate a mixture of encrypted and plain text programs. [JOHNSTONE] USPat 4120030 to Johnstone describes a computer in which the data portion of instructions are scrambled and in which the data is of necessity stored in a separate memory. There is no disclosure of operating with instructions which are completely encrypted with both the operation code and the data address portion being unreadable without a corresponding key kernel. [TWINPROGS] USPat 4183085 describes a technique for protecting software by providing two separate program storages. The first program storage is a secure storage and the second program storage is a free storage. Security logic is provided to check whether an output instruction has originated in the secure store and to prevent operation of an output unit which receives output instructions from the free storage. This makes it difficult to produce information by loading a program into free storage. [AUTHENTICATOR] USPat 3996449 entitled "Operating System Authenticator," discloses a technique for authenticating the validity of a plain text program read into a computer, by exclusive OR'ing the plain text of the program with a key to generate a code word which must be a standard recognizable code word which is successfully compared with a standard corresponding code word stored in the computer. If there is a successful compare, then the plain text program is considered to be authenticated and is allowed to run, otherwise the program is not allowed to run. ELEMENTS OF [PGP] CRACKING In order to try to crack PGP, you need to understand how these public/private keys systems work. Cracking PGP seems extremely difficult, though... I have a special dedicated "attack" computer that runs 24 hours on 24 only to this aim and yet have only begun to see the light at the famous other end of the tunnel. It's hard, but good crackers never resign! We'll see... I publish here the following only in the hope that somebody else will one day be able to help... In the public key cryptosystems, like PGP, each user has an associated encryption key E=(e,n) and decryption key D=(d,n), wherein the encryption keys for all users are available in a public file, while the decryption keys for the users are only known to the respective users. In order to maintain a high level of security a user's decoding key is not determinable in a practical manner from that user's encoding (public) key. Normally in such systems, since e.multidot.d.ident.1 (mod(1 cm((p-1),(q-1)))), (where "1 cm((p-1),(q-1))" is the least common multiple of the numbers p-1 and q-1) d can be determined from e provided p and q are also known. Accordingly, the security of the system is dependent upon the ability to determine p and q which are the prime factors of n. By selecting p and q to be large primes, the resultant composite number n is also large, and correspondingly difficult to factor. For example, using known computer-implemented factorization methods, on the order of 10.sup.9 years is required to factor a 200 digit long number. Thus, as a practical matter, although a user's encryption key E=(e,n) is public, the prime factors p and q of n are effectively hidden from anyone due to the enormous difficulty in factoring n. These aspects are described more fully in the abundant publications on digital signatures and Public-Key Cryptosystems. Most public/private systems relies on a message- digest algorithm. A message-digest algorithm maps a message of arbitrary length to a "digest" of fixed length, and has three properties: Computing the digest is easy, finding a message with a given digest "inversion" is hard, and finding two messages with the same digest "collision" is also hard. Message-digest algorithms have many applications, not only digital signatures and message authentication. RSA Data Security's MD5 message-digest algorithm, developed by Ron Rivest, maps a message to a 128-bit message digest. Computing the digest of a one-megabyte message takes as little as a second. While no message-digest algorithm can yet be secure, MD5 is believed to be at least as good as any other that maps to a 128-bit digest. As a final gift, I'll tell you that PGP relies on MD5 for a secure one-way hash function. For PGP this is troublesome, to say the least, coz an approximate relation exists between any four consecutive additive constants. This means that one of the design principles behind MD4 (and MD5), namely to design a collision resistant function, is not satisfied. You can construct two chaining variables (that only differ in the most significant bit of every word) and a single message block that yield the same hashcode. The attack takes a few minutes on a PC. From here you should start, as I did. [DOS 4GW] cracking - This is only a very provisory part of this tutorial. DOS 4GW cracking will be much better described as soon as [Lost soul] sends his stuff, if he ever does. For (parts of) the following I thank [The Interrupt]. Most applications of every OS, and also of DOS 4GW, are written in C language, coz as you'll have already learned or, either, you'll learn, only C allows you to get the "guts" of a program, almost approaching the effectiveness of assembler language. C is therefore the LANGUAGE OF CHOICE for crackers, when you prepare your tools and do not directly use assembler routines. Besides... you'll be able to find VERY GOOD books about C for next to nothing in the second hand bookshops. All the lusers are throwing money away in spades buying huge, coloured and absolutely useless books on unproductive "bloated" languages like Visual basic, C++ and Delphy. Good C new books are now rare (books on assembler language have always been) and can be found almost exclusively on the second hand market. Find them, buy them, read them, use them for your/our aims. You can find a lot of C tutorials and of C material on the Web, by all means DO IT! Be a conscientious cracker... learn C! It's cheap, lean, mean and very productive (and creative) :=) Back to the point: most stuff is written in C and therefore you need to find the "main" sub-routine inside the asm. With DOS/4GW programs, search the exe file for "90 90 90 90", almost always it'll be at the start of the compiled code. Now search for an INT_21 executed with 4C in AH, the exec to dos code (if you cannot "BPINT 21 AH=4C" with your tool, then search for the sequence "b4 4c cd 21". This is the equivalent to [mov AH,4C & int 21]: it's the most direct call, but as you'll have already learned, there are half a dozen ways to put 4C in AX, try them all in the order of their frequency). A few bytes above the INT_21 service 4C, you'll find the call to the "main" subroutine: "E8 xx xx". Now place a "CC" byte a few bytes above the call in the exe and run the exe under a debugger. When the computer tries to execute the instruction you'll be throw back in the debugger coz the "CC" byte acts as INT_01 instruction. Then proceed as usual. [THE "STEGONATED" PASSWORD HIDEOUT] A last, very nice trick should be explained to every wannabe cracker, coz it would be embarrassing to search for passwords or protection routines that (apparently) are not there. They may be hidden INSIDE a picture (or a *.waw file for that matter). This is steganography, a method of disguising messages within other media. Depending on how many shades of grey or hues of colour you want to have, a pixel can be expressed using 8. 16, 32 or even more bits. If the least significant bit is changed. the shade of the pixel is altered only one-256th, one-65,OOOth or even less. No human eye could tell the difference. What the protectionist does, is hijack the least significant bit in each pixel of a picture. It uses that bit to store one bit of a protection, or of a password (or of a file, or of a secret message). Because digitized pictures have lots of pixels, it's possible to store lots of data in a single picture. A simple algorithm will transfer them to the relevant parts of the program when it needs be, and there we'll intercept them. You'll need to learn very well the zen-cracking techniques to smell this kind of stuff though (-> see lesson B). Well, that's it for this lesson, reader. Not all lessons of my tutorial are on the Web. You 'll obtain the OTHER missing lessons IF AND ONLY IF you mail me back (via anon.penet.fi) with some tricks of the trade I may not know that YOU discovered. Mostly I'll actually know them already, but if they are really new you'll be given full credit, and even if they are not, should I judge that you "rediscovered" them with your work, or that you actually did good work on them, I'll send you the remaining lessons nevertheless. Your suggestions and critics on the whole crap I wrote are also welcomed. E-mail +ORC an526164@anon.penet.fi (+ORC) HOW TO CRACK, by +ORC, A TUTORIAL --------------------------------------------------------------------------- Lesson 8.1: How to crack Windows, an approach --------------------------------------------------------------------------- [WINPGP.EXE] -------------------------------------- -------------------------------------------------------- SPECIAL NOTE: Please excuse the somehow "unshaven" character of the windows lessons... I'm cracking the newest Windows '95 applications right now, therefore at times I had to add "on the fly" some corrections to the older Windows 3.1 and Windows NT findings. "homines, dum docent, discunt". --------------------------------------------------------- -> 1st THING TO REMEMBER The NE format does give every windows executable the equivalent of a debug symbol table: A CRACKER BLISS! -> UNDOCUMENTED DEBUGGING One of the many feature of Windows based on undocumented foundations is the "ability to debug". A word about undocumented functions in the MS-Operating Systems: Microsoft manipulates its rule and domination of the operating systems in use to day (MS-DOS, Windows, Windows '95) with two main wicked aims: 1) getting the concurrence completely bankrupt (that's the scope of all the using of undocumented functions and CHANGING them as soon as the concurrence uses them). The battle against Borland was fought in this way. 2) getting all future "programmers" to use windows as a "black box" that only Microsoft engineers (if ever) can master, so that everybody will have to sip the ill-cooked abominations from Microsoft without ever having a chance to alter or ameliorate them. Strange as it may seem, only the sublime cracker community fights against these intolerable plans. All stupid governments and lobbies -on the contrary- hide behind the fig-leaf of the "market" "freedom" in order to ALLOW such heinous developments (I'm speaking as if they were capable to opposing them even if they wanted, which they do not. Be assured, they couldn't anyway, "Governments" are deliberately MADE to serve Gates and all the remaining suckers, and lobbies are the shield of feudalism. You can forget "democracy", the only rule existing is a malevolent oligarchy based on money, personal connections, defect of culture, lack of knowledge and dictatorship of bad taste through television in order to keep the slaves tamed... enough now...) The windows situation is particularly reminiscent of the older situation in DOS, where for years the key "load but don't execute" function, used by debuggers, such as [DEBUG], [SYMDEB] and [CODEVIEW], was "reserved" by Microsoft. The windows debugging library, WINDEBUG.DLL, a number of undocumented functions and even the interface it provides are undocumented! The WinDebug() function is used by all available windows debuggers, including [CVW] (CodeView for Windows), [TDW] (TurboDebugger for Windows), [Multiscope] and [Quick C for Windows] (the last two are GUI, not text debuggers. The use of WinDebug() doesn't show up in MAPWIN output 'coz debuggers link to it at run-time via the amazing GetProcAddress() function. WinDebug() is a hacked 32-bit version, for the old Windows 3.0, of the poorly documented DOSPTrace() function from OS/2 1.x (study these older Operating Systems! Studying the past you'll understand EVERYTHING! Sometime I think that the only way to hack and crack correctly is to be more a software historian than a programmer... fac sapias et liber eris!). DOSPTrace is, in turn, based on the ptrace() function in Unix. Like DosPTrace(), WinDebug() takes commands such as Go, Single-Step, Write&Read Registers, Write&Read Memory. It returns to its caller either when the command completes or when a breakpoint occurs (or a DLL load). These commands and notifications appear in a large structure whose address is passed in WinDebug(). WinDebug() was renamed CVWIN.DLL (and TDWIN.DLL) for Windows 3.1., all crackers should study it and get the maximum possible documentation about it. As you will see in the following, it is worth to study also TOOLHELP.DLL (what Microsoft would like you to fiddle with) and INT_41h (the real debugging interface). Interrupt handling under Windows Interrupt handling under Windows can be tricky: you need to use Toolhelp (a rather scaring lobotomy for your programs) or to have special code for Standard vs. Enhanced modes, because the information on the stack of an interrupt or exception handler differs between the two windows modes. In addition, some handlers would be installed using INT_21h, while others are set up using DPMI services. Toolhelp has quite a bit of internal code that "cooks" the interrupts and sends them to you in an easily digestible form. Remember that Windows uses GP faults as a "hacker" method of doing ring transitions that are not allowed with legal 80x86 instructions: the virtual memory system of Enhanced mode is implemented via the page fault. Some tools for cracking windows (-> see lesson 9) ----------------- DEBUGGERS CVW and TDW (you have to know the function's segment:offset address beforehand in order to crack a function) WCB [Windows Codeback] by Leslie Pusztai (it's a really cool tool!) WDEB386 Microsoft's WDEB386 (clumsy, and requires a second monitor) Soft-Ice/Windows best (BY FAR!) windows debugger! NuMega is so good I am at times really sorry to crack their products! [WINICE] is the single, absolutely essential debugger and snooping utility for windows crackers. Get it! ----------------- POST MORTEM INSPECTORS CORONER, etc. (a lot of shareware) MS-DrWatson Old and clumsy Borland's Winspector THE BEST! It has the BUILDSYM utility that allows the creation of a debug .SYM file from an .EXE without debug information. ----------------- INSPECTORS MS-Spy Old Borland's WinSight (Best one, select "Other") MicroQuill's Windows DeMystifiers (from Jeff Richter): VOYEUR (hold SHIFT picking Message Selection), COLONEL, MECHANIC and ECOLOGIST ----------------- SNOOPERS [INFSPY.EXE], 231.424 bytes, version 2.05 28/8/1994 by Dean Software Design, may be the more complete one. [SUPERSPY.EXE], 24.576 bytes, 10,6,1994, quite handy for quick informations. [WINVIEW.EXE], 30.832 bytes, Version 3.00 by Scott McCraw, MS(c) 1990-1992, this is the old MS-Spy, distributed by MS [TPWSPY.EXE], 9.472 bytes, quite primitive, but you get the pascal source code with it. -> INSIDE A WINDOWS '95 DEBUGGER You can debug a program at the assembly-language level without any debugging information. The DOS [DEBUG] program does that, allowing breakpoints and single-stepping, all of which implies that the hardware must be cooperating. Back in the time of the 4-MHz Z-80s, you used a debugger that plugged interrupt op codes into the instruction stream to generate breakpoints. Nothing has changed. That's how you debug a program on a 80586 (=Pentium). The x86 architecture includes software interrupts. The 1-byte op code xCC is the INT_03 instruction, reserved for debuggers. You can put the INT_03 op code in place of the program instruction op code where the break is to occur and replace the original op code at the time of the interrupt. In the 80386 and later, you can set a register flag that tells the processor to generate a not-intrusive INT_01 instruction for every machine instruction executed. That device supports single stepping. The Win32SDK (Windows '95 software developer's kit) includes functions that allow one program to launch another program and debug it. The SDK's debug API takes care of how the interrupts and interrupt vectors get managed. The logical consequence of such an approach is that fewer and fewer people will be able to know what's going on inside an application. The bulk of the programmers -in few years time- will not be able any more to reverse engineer an application, unless the few that will still understand assembler-language do offer them the tools to do it. Microsoft -it is evident- would like the programmers to use a "black box" approach to programming, writing nice little "hallo world" application and leaving to the engineers in Microsoft alone the capacity to push forward (and sell) real programs that are not toy application. The Win32 documentation seems vast, almost luxurious, until you begin serious work and you discover its shortcomings, like the fact that extended error codes are not documented, and numerous APIs are documented either incorrectly or so poorly that you must burn precious time testing them. What we definitely need is to find some secret fellows inside Microsoft (like good old Prometeus) that smuggles to the outside the real documentation that the Microsoft engineers have reserved for themselves. If you are reading this and do work for Microsoft, consider the possibility of double-crossing your masters for the sake of humanity and smuggle us the secret information. In windows '95 a debugger program launches a program to be debugged by calling the _CreateProcess function, specifying in an argument that the program is to be debugged. Then the debugger program enters a loop to run the program. At the top of the loop the debugger calls _WaitForDebugEvent. Each time _WaitForDebugEvent returns it sets indicators that tell about the vent that suspended the program being debugged. This is where the debugger traps breakpoints and single-step exceptions. _WaitForDebugEvent fills in an event structure that contains among other things the address that was interrupted end the event that caused the interrupt. The debugger calls _GetThreadContext to get the running context of the debugged program, including the contents of the registers. The debugger can, as the result of cracker interaction, modify these values and the contents of the debugged program's memory. The debugger sets breakpoints by saving the op code at the instruction to be intercepted and putting the INT_03 op code at its place, it's always the same old marmalade. When the breakpoint occurs, the debugger replaces the original op code in the program's instruction memory, and decrements the interrupted program counter in the saved context so that execution resumes at the instruction that was broken. To single-step a program, the debugger sets a bit in the context's flags register that tells the processor to generate an INT_01 for every instruction cycle. When that interrupt occurs, the debugger checks to see if the interrupted address is at a new source-code line number. If not, the debugger continues execution. Otherwise, the debugger displays the new line in the IDE and waits for the cracker to take an action that resumes the program. While the debugged program is suspended, the debugger interacts with the cracker and provides full access to the debugged program's context and memory. This access permits the cracker to examine and modify part of the code. To resume the debugged program, the debugger resets the program's context by calling _SetThreadContext and calls _ContinueDebugEvent. Then, the debugger returns to the top of the loop to call _WaitForDebugEvent again. To extract debug information from a Win32 executable file, you must understand the format of that file (best thing to do, to practice yourself, would be to reverse engineer small programs). The executable file has two sections not found in other executable files: ".stab" and ".stabstr". How nice that they used names that suggest their purpose (nomen est omen). You'll find them inside a table of fixed-length entries that include entries for .text, .bss, .data and .idata. Inside these sections the compilers put different parts of a program. There are several different formats for encoding debug information in an executable file. Borland's Turbo Debugger one format. Microsoft's CodeView another. The gnu-win32 port from Cygnus the stab format, an acronym meaning "symbol table", although the table contains much more than just symbol information. The .stab section in a portable executable file is a table of fixed-length entries that represent debugging information in the stab format. The .stabstr section contains variable-length, null terminated strings into which the .stab table entries point. The documentation for the stab format is available in text format on the Cygnus ftp site (ftp.cygnus.com//pub/gnu-win32). Stabs contain, in a most cryptic format, the names and characteristics of all intrinsic and user-defined types, the memory address of every symbol in external memory and on the stack, the program counter address of every function, the program counter address where every brace-surrounded statement block starts and ends, the memory address of line numbers within source-code files, and anything else that a debugger needs. The format is complex and cryptic because it is intended to support any source-code language. It is the responsibility of a debugger program to translate the stab entries into something meaningful to the debugger in the language being debugged. Windows '95 invokes dozens of INT_21 services from 32-bit code, including KERNEL32.DLL and possess Krn32Mutex, which apparently controls access to certain parts of the kernel. Some of the functions in KERNEL32 can be blocked by the Win16Mutex, even though Microsoft says this isn't the case. SO, I WANNA CRACK, WHAT SHOULD I DO? I'll show you a simple windows crack, so easy it can be done without WINICE: let's take [WINPGP4.1.] (front-end for PGPing in windows, by Geib - I must thank "Q" for the idea to work on this crack). Using WCB you'll find out quickly that the "CONGRATULATIONS your registration number is OK" and the "SORRY, your registration number is not correct" data blocks are at the block starting at 36.38B8 (respectively at 36.38D5 and 36.3937), that relocs to 13.081B. Looking at 13.0000 and following code, you'll find a push 38D5 (68D538) and a push 3937 (683739) at 13.064D and 13.06AE. The road to the crack is now open, you just need to find and "fool" the calling routines. You'll learn the exact procedures for this kind of WINcracks in part 2 and 3 of -> Lesson 8. Let's now have a look at the protection scheme (disassembly from WCB): ... 13.0E88 660FBF46F8 movsx eax, word ptr [bp-08] 13.0E8D 668946F4 mov [bp-0C], eax 13.0E91 668B46F4 mov eax, [bp-0C] 13.0E95 6669C00A000300 imul eax, 0003000A 13.0E9C 668946F0 mov [bp-10], eax 13.0EA0 668B4606 mov eax, [bp+06] 13.0EA4 663B46F0 cmp eax, [bp-10] 13.0EA8 7505 jne 0EAF <- beggar_off 13.0EAA B80100 mov ax, 0001 <- flag 1 = "Right!" 13.0EAD EB04 jmp 0EB3 <- and go on beggar_off: 13.0EAF 33C0 xor ax,ax <- flag 0 = "Nope!" 13.0EB1 EB00 jmp 0EB3 <- and go on I want you to have a good look at this protection scheme. IT'S THE SAME OLD SOUP! You do remember lesson 3 and the protection schemes of the old DOS stupid games of the '80s, don't you? IT'S THE SAME OLD SOUP! In this "up-to-date" "new" windows application, in WINPGP version 4.1 of 1995/1996, exactly the same kind of protection is used to "conceal" the password! A) compare user input with memory echo B) beggar off if not equal with AX=0 C) go on if equal with AX=1... how boring! Besides, look at all the mov eax, and eax, moves preceding the compare! That's a typical pattern for these "number_password" protections! I wrote (years ago) a little crack utility that searches for code blocks with a "66" as first instruction_byte repeating in four or more consecutive instructions and it still allows me to crack more than half of these windows password smuts in less than three seconds flat. The IMUL instruction creates the "magic" number, and if you give a closer look at the mathematical part of the "conceal" routine, it could help you to crack analogous schemes used in order to protect the "Instant access" (c) & (tm) time_crippled software :=) Now you could crack the above code in 101 different ways, the most elegant one would probably substitute je 0EAF (or jZ 0EAF, that's the same) to the jne 0EAF at 13.0EA8. You just write a 74 at the place of the 75, like you did for the cracks in 1978... how boring: it's really the same old soup! (But you'll see some new tricks in the next lessons). Well, that's it for this lesson, reader. Not all lessons of my tutorial are on the Web. You 'll obtain the missing lessons IF AND ONLY IF you mail me back (via anon.penet.fi) with some tricks of the trade I may not know that YOU discovered. Mostly I'll actually know them already, but if they are really new you'll be given full credit, and even if they are not, should I judge that you "rediscovered" them with your work, or that you actually did good work on them, I'll send you the remaining lessons nevertheless. Your suggestions and critics on the whole crap I wrote are also welcomed. E-mail +ORC +ORC 526164@anon.penet.fi HOW TO CRACK, by +ORC, A TUTORIAL --------------------------------------------------------------------------- Lesson 8.2: How to crack Windows, a deepr approach --------------------------------------------------------------------------- [SNAP95] [WINZIP] [WINCAT] -------------------------------------- SPECIAL NOTE: Please excuse the somehow "unshaven" character of the windows lessons... I'm cracking the newest Windows '95 applications right now, therefore at times I had to add "on the fly" some corrections to the older Windows 3.1 and Windows NT findings. "homines, dum docent, discunt". --------------------------------------------------------- -> 1st THING TO REMEMBER If you thought that DOS was a mess, please notice that windows 3.1 is a ghastly chaos, and windows 95 a gruesome nightmare of ill-cooked spaghetti code. Old Basic "GOTO" abominations were quite elegant in comparison with this concoction... One thing is sure: This OS will not last... it's way too messy organised, impossible to consolidate, slow and neurotic (but I must warn you... I thought exactly the same things about DOS in 1981). The most striking thing about windows 95 is that it is neither meat not fish: neither 16 nor 32... you could call it a "24 bit" operating system. We'll never damage Microsoft interests enough to compensate for this moronic situation... where you have to wait three minutes to get on screen a wordprocessor that older OS (and even old DOS) kick up in 5 seconds. I decide therefore, hic et nunc, to add an ADDENDUM to this tutorial: Addendum 1 will be dedicated to teach everybody how to crack ALL Microsoft programs that do exist on this planet. I'll write it this sommer and give it away between the "allowed" lessons. Anyway you can rely on good WINICE to crack everything, you'll find it on the web for free, I use version 1.95, cracked by [The Lexicon] (do not bother me for Warez, learn how to use the search engines on the web and fish them out yourself). Learn how to use this tool... read the whole manual! Resist the temptation to crack immediatly everything in sight... you 'll regret pretty soon that you did not wanted to learn how to use it properly. A little tip: as Winice is intended more for software developers than for crackers, we have to adapt it a little to our purposes, in order to make it even more effective: a good idea is to have in the *.DAT initialization file following lines: INIT = "CODE ON; watchd es:di; watchd ds:si;" TRA = 92 This way you'll always have the hexadecimal notation on, two very useful watch windows for passwords deprotection and enough buffer for your traces. WINDOWS 3.1. basic cracking: [ALGEBRAIC PROTECTIONS] The most used windows protections are "registration codes", these must follow a special pattern: have a "-" or a "+" in a predetermined position, have a particular number in particular position... and so on. For the program [SHEZ], for instance, the pattern is to have a 14 bytes long alphanumeric sequence containing CDCE1357 in the first 8 bytes. The second level of protection is to "connect" such a pattern to the alphanumeric contents of the NAME of the user... every user name will give a different "access key". This is the most commonly used system. As most of these protections have a "-" inside the answering code, you do not need to go through the normal cracking procedure (described in the next lesson): * load WINICE * hwnd [name_of_the_crackanda_module] * choose the window Handle of the snap, i.e, the exact "FIELD" where the code number input arrives... say 091C(2) * BMSG 091C WM_GETTEXT * Run anew * Look at the memory location(s) * Do the same for the "Username" input FIELD. (Sometimes linked, sometimes not, does not change much, though) * BPR (eventually with TRACE) on the memory locations (these will be most of the time FOUR: two NUMBERCODES and two USERNAMES). The two "mirrored" ones are the most important for your crack. At times there will be a "5th" location, where the algebraic play will go on... * Look at the code that performs algebraic manipulations on these locations and understand what it does... * Disable the routine or jump over it, or reverse it, or defeat it with your own code... there are thousand possibilities... * Reassemble everything. Uff... quite a long cracking work just to crack some miserable program... isn'there a quicker way? OF COURSE THERE IS! Actually there are quite a lot of them (see also the crack of Wincat Pro below): Look at the following code (taken from SNAP32, a screen capture utility for Windows 95, that uses a pretty recent protection scheme): XOR EBX,EBX ; make sure EBX is zeroed MOV BL, [ESI] ; load input char in BL INC ESI ; point at the next character MOV EDI,EBX ; save the input character in EDI CMP EBX,+2D ; input char is a "-" ? JZ ok_it's_a_+_or_a_- CMP EBX,+2B ; input char is a "+" ? JNZ Jesus_it's_neither_a_minus_nor_a_plus_let's_check_it :ok_it's_a_+_or_a_- XOR EBX,EBX ; EBX is zeroed MOV BL,[ESI] ; recharge BL INC ESI ; point to next char (do not check - or +) :Jesus_it's_neither_a_minus_nor_a_plus_let's_check_it XOR EBP,EBP ; zero EBP CMP DWORD PTR [boguschecker], +01 ... even if you did not read all my precedent lessons, you do not need much more explications... this is a part of the algebraic check_procedure inside the SNAP32 module... you could also get here through the usual USER!BOZOSLIVEHERE KERNEL!HMEMCPY USER!GLOBALGETATOMNAME Windows wretched and detestable APIs used for copy protections, as usual with WINICE cracking, and as described elsewhere in my tutorial. The above code is the part of the routine that checks for the presence of a "+" or a "-" inside the registration number (many protections scheme requires them at a given position, other need to jump over them). Now sit down, make yourself comfortable and sip a good Martini- Wodka (invariably very useful in order to crack... but be aware that only Moskowskaia russian Wodka and a correct "Tumball" glass will do, do not forget the lemon)... what does this "-" stuff mean for us little crackers? It means that we can search directly for the CMP EBX,+2B sequence inside any file protected with these schemes... and we'll land smack in the middle of the protection scheme! That's amazing... but you will never underrate enough the commercial programmers... the only really amazing thing is how simpleton the protectionists are! You don't believe me? Try it... you 'll get your crack at least 4 out of 5 times. Yes I know, to find this code is not yet to crack it... but for this kind of copy protection (that's the reason it is so widespread) there is no single solution... each makes a slightly different algebraic manipulation of the alphanumeric and of the numeric data. It's up to you to crack the various schemes... here you can only learn how to find them and circumvene them. I'll not give you therefore a "debug" crack solution. You'll find it yourself using my indications (see the crack of the Wincat Pro program below). WHERE ARE THE CODES? WHERE ARE THE MODIFIED FILES? WHERE DO THE PROTECTIONS KEEP COUNT OF THE PASSING DAYS? Most of the time the protection schemes use their own *.ini files in the c:\WINDOWS directory for registration purposes... at time they even use the "garbage sammler" win.ini file. Let's take as example WINZIP (versions 5 and 5.5), a very widespread program, you'll surely have one shareware copy of it somewhere between your files. In theory, winzip should be registered per post, in order to get a "NEW" copy of it, a "registered" copy. This scares most newby crackers, since if the copy you have it's not full, there is no way to crack it and make it work, unless you get the REAL stuff. The youngest among us do not realize that the production of a real "downsized" demo copy is a very expensive nightmare for the money-infatuated commercial programmers, and that therefore almost nobody does it really... nearly all "demos" and "trywares" are therefore CRIPPLED COMPLETE PROGRAMS, and not "downsized" demos, independently of what the programmers and the protectionists have written inside them. Back to Winzip... all you need, to crack winzip, is to add a few lines inside the win.ini file, under the heading [WinZip], that has already been created with the demo version, before the line with "version=5.0". I will not help you any further with this... I'll leave it to you to experiment with the correct sequences... inside win.ini you must have following sequence (these are only template to substitute for your tries inside WINICE... you'll get it, believe me): [WinZip] name=Azert Qwerty sn=######## version=5.5 The *important* thing is that this means that you DO NOT NEED to have a "new registered version" shipped to you in order to make it work, as the protectionist sellers would like you to believe. The same applies most of the time... never believe what you read in the read.me or in the registration files... This brings me to a broader question: NEVER believe the information they give you... never believe what television and/or newspapers tell you... you can be sure that the only reason they are notifying you something is to hinder you to read or understand something else... this stupid_slaves_society can only subsist if nobody thinks... if you are really interested in what is going on, real information can be gathered, but surely not through the "conventional" newspapers and/or news_agencies (and definitely NEVER through television, that's really only for the stupid slaves)... yes, some bit of information can be (laboriously) gathered... it's a cracking work, though. HOW TO CRACK INFORMATION [WHERE WHAT] * INTERNET In the middle of the hugest junk collection of the planet, some real information can be laboriously gathered if you do learn how to use well the search engines (or if you do build your ones... my spiders are doing most of the work for me... get your robots templates from "Harvest" or "Verify" and start your "spider building" activity beginning from Martijn Koster's page). As usual in our society, in the Internet the real point is exactly the same point you'll have to confront all your life long: HOW TO THROW AWAY TONS OF JUNK, HOW TO SECLUDE MYRIADS OF USELESS INFORMATION and HOW TO FISH RARE USEFUL INFORMATION, a very difficult art to learn per se. Internet offers some information, though, mainly BECAUSE it's (still) unregulated. You want a proof? You are reading it. * SOME (RARE) NEWSPAPERS. The newspaper of the real enemies, the economic powers that rule this slaves world, are paradoxically most of the time the only ones worth studying... somewhere even the real rulers have to pass each other some bits of real information. The "Neue Zuercher Zeitung", a newspaper of the Swiss industrials from Zuerich, is possibly the best "not_conformist trend analyzer" around that you can easily find (even on the web). These swissuckers do not give a shit for ideology, nor preconcerted petty ideas, the only thing they really want is to sell everywhere their ubiquitous watches and their chocolates... in order to do it, a land like Switzerland, with very high salaries and a good (and expensive) social system, must use something brilliant... they found it: a clear vision of the world... as a consequence this newspaper is very often "against" the trend of all the other medias in the world, the ones that are used only in order to tame the slaves... If the only language you know is english (poor guy) you could try your luck with the weekly "Economist"... you'll have to work a lot with it, coz it has been tailored for the "new riches" of the Tatcher disaster, but you can (at times) fish something out of it... they do a lot of idiotic propaganda, but are nevertheless compelled to write some truth. American newspapers (at least the ones you can get here in Europe) are absolute shit... one wonders where the hell do the americans hyde the real information. On the "non-capitalistic" side of information there is a spanish newspaper "El Pais" that seems to know about what's going on in South America, but it's so full of useless propaganda about irrelevant Spanish politics that it's not really worth reading. The monthly "Le Monde diplomatique" offers something too... this one exaggerates a little on the pauperistic "third world" side, but has a lot of useful information. See what you can do with all this information (or disinformation?) [BELIEVE THE COUNTRARY] Another good rule of thumb in choosing your medias is the following... if all medias around you assure, for instance, that "the Serbians are evil"... the only logical consequence is that the Serbians are not so evil at all and that "the Croats" or some other Yugoslavian shits are the real culprits. This does not mean at all that the Serbians are good, I warn you, it means only what I say: something is surely hidden behind the concerted propaganda you hear, the best reaction is to exaggerate in the other direction and believe the few bit of information that do say the countrary of the trend. This rule of thumb may be puerile, but it works somehow most of the time... if somewhere everybody writes that the commies are bad then THERE the commies must not be so bad at all and, conversely, if everybody in another place writes that the commies are all good and nice and perfect (like the Soviet propaganda did) then THERE the commies are surely not so good... it's a matter of perspective, much depends on where you are, i.e. whose interests are really at stake. There is NEVER real information in this society, only propaganda... if you still do not believe me do yourself a little experiment... just read the media description of a past event (say the Vietnam war) as written AT THE MOMENT of the event and (say) as described 10 years later. You'll quickly realize how untrustworthy all newspapers and medias are. * SEMIOTICS You'll have to study it (as soon as you can) to interpret what they let you believe, in order to get your bearings. A passing knowledge of ancient RHETORIC can help quite a lot. Rhetoric is the "Softice" debugger you need to read through the propaganda medias: concentrate on Periphrasis, Synecdoche, Antonomasia, Emphasis, Litotes and Hyperbole at the beginning... you'll later crack higher with Annominatio, Polyptoton, Isocolon and all the other lovely "figurae sententiae". Enough, back to software cracking. HOW A REGISTRATION CODE WORKS [WINCAT] Let's take as an example for the next crack, a Username- algebraic registration code, WINCAT Pro, version 3.4., a 1994 shareware program by Mart Heubel. It's a good program, pretty useful to catalogue the millions of files that you have on all your cd-roms (and to find them when you need them). The kind of protection Wincat Pro uses is the most utilized around: the username string is manipulated with particular algorithms, and the registration key will be made "ad hoc" and depends on the name_string. It's a protection incredibly easy to crack when you learn how the relevant procedures work. [WINCAT Pro] is a good choice for cracking studies, coz you can register "over your registration" one thousand times, and you can herefore try for this crack different user_names to see all the algebrical correspondences you may need to understand the protection code. In this program, when you select the option "register", you get a window where you can input your name and your registration number (that's what you would get, emailed, after registering your copy). If you load winice and do your routinely hwnd to individuate the nag window, and then breakpoint on the appropriate memory ranges you'll peep in the working of the whole bazaar (this is completely useless in order to crack these schemes, but it'll teach you a lot for higher cracking, so you better do it also with two or three other programs, even if it is a little boring): a series of routines act on the input (the name) of the user: the User_name_string (usn). First of all the usn_length will be calculated (with a REPNZ SCASB and a following STOSB). Then various routines store and move in memory the usn and the registration_number (rn) and their relative lengths. In order to compare their lengths and to check the correct alphanumeric correspondence between usn and rn, the program first uppercases the usn and strips all eventual spaces away. Here the relevant code (when you see an instruction like SUB AL,20 you should immediately realize that you are in a uppercasing routine, which is important for us, since these are mostly used for password comparisons)... here the relevant Winice unassemble and my comments: 253F:00000260 AC LODSB <- get the usn chars 253F:00000261 08C0 OR AL,AL <- check if zero 253F:00000263 740F JZ 0274 <- 0: so usn finished 253F:00000265 3C61 CMP AL,61 <- x61 is "a", man 253F:00000267 72F7 JB 0260 <- not a lower, so loop 253F:00000269 3C7A CMP AL,7A <- x7A is "z", what else? 253F:0000026B 77F3 JA 0260 <- not a lower, so loop 253F:0000026D 2C20 SUB AL,20 <- upper it if it's lower 253F:0000026F 8844FF MOV [SI-01],AL<- and hyde it away 253F:00000272 EBEC JMP 0260 <- loop to next char 253F:00000274 93 XCHG AX,BX ... The instruction MOV [SI-01],AL that you see here is important at times, coz it points to the location of the "pre-digested" usn, i.e. the usn formatted as it should be for the number comparison that will happen later. In some more complicated protection schemes the reasoning behind this formatting is the following: "Stupid cracker will never get the relation algorhitm usn <-> rn, coz he does not know that usn AND rn are slightly changed before comparing, ah ah... no direct guessing is possible". Here is only "polishing": you have to "polish" a string before comparing it in order to concede some mistakes to the legitimate user (too many spaces in the name, upper-lower case mismatch, foreign accents in the name etc.) You just need to know, for now, that this checking is usually still 5 or 6 calls ahead of the real checking (it's what we call a "green light"). You should in general realize that the real checking of the algebrical correspondence follows after a whole series of memory operations, i.e.: cancelling (and erasing) the previous (if ever) attempts; reduplicating the usn and the rn somewhere else in memory; double checking the string lengths (and saving all these values somewhere... be particularly attentive when you meet stack pointers (for instance [BP+05]): most of the programs you'll find have been written in C (what else?). C uses the stack (SS:SP) to pass parameters or to create local variables for his procedures. The passwords, in particular, are most of the time compared to data contained within the stack. If inside a protection a BP register points to the stack you have most of the time fished something... remember it pupils: it will spare you hours of useless cracking inside irrelevant routines. Back to our CATWIN: another little check is about the "minimal" length allowed for a user name, in our babe, for instance, the usn must have at least 6 chars: 230F:00003483 3D0600 CMP AX,0006 230F:00003486 730F JAE 3497 <- go to nice_name :too_short 230F:00003488 BF9245 MOV DI,4592 <- no good: short After a lot of other winicing you'll finally come across following section of the code: 2467:00000CA3 B90100 MOV CX,0001 2467:00000CA6 03F1 ADD SI,CX 2467:00000CA8 2BC1 SUB AX,CX 2467:00000CAA 7213 JB 0CBF 2467:00000CAC 40 INC AX 2467:00000CAD 368B4F04 MOV CX,SS:[BX+04] <- here 2467:00000CB1 0BC9 0R CX,CX 2467:00000CB3 7D02 JGE 0CB7 2467:00000CB5 33C9 XOR CX,CX 2467:00000CB7 3BC1 CMP AX,CX 2467:00000CB9 7606 JBE 0CC1 2467:00000CBB 8BC1 MOV AX,CX 2467:00000CBD EB02 JMP 0CC1 2467:00000CBF 33C0 XOR AX,AX 2467:00000CC1 AA STOSB <- and here 2467:00000CC2 8BC8 MOV CX,AX 2467:00000CC4 F3A4 REPZ MOVSB <- and here! 2467:00000CC6 8EDA MOV DS,DX 2467:00000CC8 FC RETF 0008 This is obviously the last part of the checking routine (I'll not delve here with the mathematical tampering of it, if you want to check its workings, by all means, go ahead, it's quite interesting, albeit such study is NOT necessary to crack these schemes). The important lines are obviously the MOV CX,SS:[BX+04], the STOSB and the REPZ MOVSB (as usual in password protection schemes, you do remember lesson 3, don't you?). You should be enough crack-able :=) by now (if you have read all the precedent lessons of my tutorial), to find out easily, with these hints, how the working of the protection goes and where dwells in memory the ECHO of the correct rn (passkey) that matches the name you typed in. Remember that in these kind of cracks the ECHO is present somewhere (90% of the cases). There are obviously one thousand way to find such ECHOs directly, without going through the verificayions routines... for instance you could also find them with a couple of well placed snap_compares, it's a "5 minutes" cracking, once you get the working of it. I leave you to find, as interesting exercise, the routine that checks for a "-" inside the rn, a very common protection element. In order to help you understand the working of the protection code in [Wincat Pro] I'll give you another hint, though: if you type "+ORC+ORC+ORC" as usn, you'll have to type 38108-37864 as rn, if you usn as usn "+ORC+ORC" then the relative rn will be 14055-87593. But these are my personal cracks... I have offered this information only to let you better explore the mathematical tampering of this specific program... you'll better see the snapping mechanism trying them out (going through the routines inside Winice) alternatively with a correct and with a false password. Do not crack Wincat with my combination! If you use a different usn than your own name to crack a program you only show that you are a miserable lamer... no better than the lamers that believe to "crack" software using huge lists of serial numbers... that is really software that they have stolen (Yeah: stolen, not cracked). You should crack your programs, not steal them... "Warez_kids" and "serial#_aficionados" are only useless zombies. I bomb them as soon as I spot them. YOU ARE (gonna be) A CRACKER! It makes a lot of a difference, believe me. Well, that's it for this lesson, reader. Not all lessons of my tutorial are on the Web. You 'll obtain the missing lessons IF AND ONLY IF you mail me back (via anon.penet.fi) with some tricks of the trade I may not know that YOU discovered. Mostly I'll actually know them already, but if they are really new you'll be given full credit, and even if they are not, should I judge that you "rediscovered" them with your work, or that you actually did good work on them, I'll send you the remaining lessons nevertheless. Your suggestions and critics on the whole crap I wrote are also welcomed. "If you give a man a crack he'll be hungry again tomorrow, but if you teach him how to crack, he'll never be hungry again" E-mail +ORC an526164@anon.penet.fi HOW TO CRACK, by +ORC, A TUTORIAL --------------------------------------------------------------------------- Lesson 9 (1): How to crack Windows, Hands on --------------------------------------------------------------------------- [Winformant][Snap32] -------------------------------------- THE [DATA_CONSTRAINT] TRICK - [WINFORMANT 4] I have chosen an older windows application for Win 3.1. (WIN4MANT.EXE, 562271 bytes, Version 1.10, by Joseph B. Albanese; you'll find it searching the web with the usual tools, see how to do it at the end of this lesson), in order to show you how to use a nice little trick, at times really useful in cracking password protected programs: [data_constraint]. Inside almost all protection routines, as you have already learned, there is a moment when on the stack the ECHO of the real, "correct" passnumber or password appears. The location of this ECHO varies, but most of the time it'll be in a range of +- 0x90 bytes from one of the locations where the user input dwells. This is due to datadump windows constraints inside the tools used by the protectionists... but this use is bound to diminish... especially after this lesson :=) [WINFORMANT CRACKING] This application is -per se- crappy, I doubt you'll ever use it... but its curious (and pretty rare) "deactivate" mode is nevertheless very interesting for us: you can "unregister" Winformant on the fly if you feel the need to. This feature is pretty useful for scholars that like to investigate password algorithms with valid and invalid codes without having to reinstall every time to delete a valid code. For your cracking exercises choose programs that have "REVERSIBLE" protections (rare) or that can be re-registered a billion times (more frequent). Programs that keep the valid registration on *.ini or special files will also do the job: you just change a couple of lines to "unregister" them. The trick of this lesson: [data_constraint], or "password proximity", bases on the protectionist's need to keep an eye on the protection "working" when he assembles it. He must "see" the relationships between USER INPUT NUMBER, USER INPUT TRANSFORMED and the CORRECT NUMBER ANSWER (in our jargon: the "Bingo"). These relationships must be constantly checked In order to debug the protection code. Mostly they will dwell TOGETHER inside a small stack area, allowing them to be "seen" in the SAME watchwindow. Most of the time, therefore, the "ECHO" will "materialize" shortly not very far away from one of the locations of the USER INPUT. Let's crack: * Fire Winice and then Winformant * Choose HELP and then choose REGISTRATION * Fill the registration fields with "+ORC+ORC" as "Registrant" and "12121212" as "Activation" code (use whatever you fancy). CTRL+D ;switch to Winice :task ;let's see what's the name of this crap TaskName SS:SP StackTop StackBot StackLow TaskDB hQueue Events WINWORD 1AD7:85F2 4A52 8670 7532 1247 122F 0000 PROGMAN 1737:200A 0936 2070 1392 066F 07F7 0000 DISKOMAT *2C5F:6634 1D3C 6AC6 5192 2CB7 2C9F 0000 :hwnd DISKOMAT ;which window is getting the input? WinHandle Hqueue QOwner Class Name Window Procedure 0EB4(0) 2C9F DISKOMAT #32769 04A7:9E6B 0F34(1) 2C9F DISKOMAT #32768 USER!BEAR306 365C(1) 2C9F DISKOMAT #32770 2C3F:0BC6 36BC(2) 2C9F DISKOMAT Button 2C3F:1CEA 3710(2) 2C9F DISKOMAT Edit 2C3F:24BE ... and many more irrelevant windows. Let's pinpoint the code, here the relevant window is the first "Edit" one, for obvious reasons (more on this later). :bmsg 3710 wm_gettext ;set breakpoint CTRL+D ;run the babe until you get: Break Due to BMSG 3710 WM_GETTEXT C=01 Hwnd=3710 wParam=0050 lParam=2C5F629A msg=000D WM_GETTEXT 2C3F:000024BE B82F2C MOV AX,2C2F So! Now we have "pinpointed" the babe (more on "pinpointing" later). Let's snoop around a little: look at the stack to fetch your babe's last call (if it does not show immediately, just keep pinpointing, for instance on GetWindowText() or do a BPRW diskomat (very useful), and then try and retry the stack... should this too fail to work, search for your input in memory (in the 30:0 lffffffff selector, as usual) and breakpoint range on it with ReadWrite, and then stack, stack, stack... until you get the "real" list of calls coming from your babe's protection. :stack ; let's see USER(19) at 073F:124C [?] through 073F:1239 CTL3D(02) at 2C3F:0D53 [?] through 2C3F:0D53 DISKOMAT(01) at 2C97:20B9 [?] through 2C97:20B9 DISKOMAT(01) at 2C97:3D94 [?] through 2C97:3D94 DISKOMAT(01) at 2C97:49E2 [?] through 2C97:4918 DISKOMAT(04) at 2C7F:EA20 [?] through 2C7F:EA20 USER(01) at 04A7:19BE [?] through USER!GETWINDOWTEXT == CTL3D(02) at 2C3F:24BE [?] through 04A7:3A3Cµ Beautiful stack fishing! Do immediately a BPX on babe:EA20. 2C7F:EA35 9A25ABA704 CALL USER!GETWINDOWTEXT 2C7F:EA3A 8D46AE LEA AX,[BP-52] ;load ptr "+ORC+ORC" 2C7F:EA3D 16 PUSH SS ;save pointer segment 2C7F:EA3E 50 PUSH AX ;save pointer offset 2C7F:EA3F 9A768D872C CALL 2C87:8D76; get strlen "ORC+ORC" 2C7F:EA44 83C404 ADD SP,+04 2C7F:EA47 3D2800 CMP AX,0028 2C7F:EA4A 762C JBE EA78 ... 2C7F:EA97 8D46AE LEA AX,[BP-52] ;load ptr "+ORC+ORC" 2C7F:EA9A 16 PUSH SS ;various algors on input 2C7F:EA9B 50 PUSH AX ;follow here, we do not ... ;need to care 2C7F:EAB2 0F851101 JNE EBC7 2C7F:EAB6 8D8E5CFF LEA CX,[BP+FF5C] ;ptr "12121212" 2C7F:EABA 16 PUSH SS 2C7F:EABB 51 PUSH CX 2C7F:EABC 9A768D872C CALL 2C87:8D76 ;get strlen "12121212" 2C7F:EAC1 83C404 ADD SP,+04 2C7F:EAC4 50 PUSH AX 2C7F:EAC5 8D865CFF LEA AX,[BP+FF5C] ;ptr "12121212" HERE! 2C7F:EAC9 16 PUSH SS 2C7F:EACA 50 PUSH AX ...etc, various algors on input follow here OK, it's enough: now obviously follows the code that "algorithmize" the number string, and then, somewhere, you'll have the hideous compare that divides good guys and bad crackers. You could examine, and crack, and search... BUT NOW IT'S THE "MAGIC MOMENT" OF THE ECHO! We know and *feel* it: The echo must be somewhere... how do we find it? Searching "12121212" in memory fishes at least 10 different locations... :s 30:0 lffffffff '12121212' Pattern Found at 0030:0005AD6A .... (7 more) Pattern Found at 0030:80509D6A Pattern Found at 0030:8145AD6A Should we look for all occurrences of string '12121212', starting with the two at 80000000, dumping +-0x90 around it... until we find the echo? We could, and it would work, but that's not zen... that's boring! In other protections these locations could proliferate on purpose, to deter the casual cracker. There must be some other way... And lo and behold! YES! There is a quicker way... THE LAST loading of the numeric input string in the code (the one after the strlen count) is the "right" one for our cracking purposes, coz protections follow (mostly) this pattern (remember: we are inside a "stack-heavy" section of the code... if you want to crack higher I suggest you read some good literature about stack working, stack tricks and stack magics with the Intel processors): LOAD NAMEString - COUNT NAMEStringLen LOAD NAMEString - TRANSFORM NAMEString LOAD CODEString - COUNT CODEStringLen LOAD CODEString *ECHO must be here* TRANSFORM CODEString *ECHO must be here* COMPARE TRANSFORMED_NAMEString WITH TRANSFORMED_CODEString This means that at line 2C7F:EAC5 8D865CFF LEA AX,[BP+FF5C] ;ptr "12121212" you'll already have your echo somewhere... just dump the memory around the pointer [BP+FF5C]: :d 2c5f:61e8 ;these numbers will differ in your computer 02 62 2F 06 02 00 26 2E-A3 4E A3 4E 01 00 38 30 .b/...&..N.N..80 33 37 2D 36 34 36 2D 33-38 33 36 00 01 06 02 00 37-646-3836..... 2F 06 75 62 C3 2E B7 04-F2 24 2F 06 CE 6E 2F 06 /.ub.....$/..n/. 49 00 5A 00 01 00-04 2C 2F 06 AE 24 36 62 00 00 I.Z......,/..$6b 74 62 7A 2E B7 04 36 62-01 00 C2 62 2F 2C 26 2E tbz...6b...b/,&. 03 01 BA 0F AE 24 5F 02-C9 01 5E 02 BA 01 5F 02 .....$_...^..._. 31 32 31 32 31 32 31 32-00 0C 00 BC 02 00 00 00 12121212........ 00 49 00 BA 0F-AE 24 F2 24 2F 06 00 00 00 00 00 ....I....$.$/... AF 17 00 E2 5F-7A 62 FE FF 79 1B BA 0F 00 00 00 ......._zb..y... 96 0B 01 00 02 4E 00-37 01 8A 62 D2 0F 8F 17 00 .....N..7..b.... 2F 06 00 37 01-98 62 20 10 16 03 2F 06 00 00 00 /.....7..b .../. C2 62 2B 4F 52 43 2B 4F-52 43 00 0D AE 24 2F 06 .b+ORC+ORC...... Look at this dump: everybody is there! The stack pointers points in the middle, at string "12121212". 0x50 bytes before it you'll find our good old ECHO (i.e. the CORRECT passnumber) and 0x50 bytes afterwards you'll see your handle: here "+ORC+ORC". It's cracked! The code for my "+ORC+ORC" is 8037-646-3836... Now begin your assignments: if you rally want to learn cracking: - "Unregister" and find anew your own code for your own handle. *DO NOT* use serial numbers with any other name that your own handle, that's miserable stealing, not cracking. I'll begin to punish the serial#_aficionados on the Web, coz I like real outlaws, but I detest stupid pickpockets. - Study the two coding algorithms, the one for the input name and the one for the input number, this will be very useful for your future cracking sessions. - Find the "Compare", i.e. the code that sets the two usual flags "good guy, you may move on" and "bad cracker, beggar off", and - Create a "real" crack for this protection, that will allow anybody you think deserves it, with any name and any password number, to get through. [CRACKING SNAP 32] Snap 32 (SNAP32.EXE 356.352 bytes, 24/11/95, Version 2.54, by Greg Kochaniak) is a "snapshot" shareware program for Windows 95, that allows users to save the screen, parts of it, or a single window. It's a very common 'try before you buy' program, limited to 30 days use. You'll find it everywhere on the Web. If you do not know how to search the Web (poor guy!), learn at the end of this lesson the correct procedure to find all the files you need on the Net and get them automatically emailed to you (that's something you should learn: SEARCHING! It's even more important than cracking!). Snap32 is not very interesting (I don't think I used it more than a couple of times), but its protection is: in order to (try to) deter casual crackers it does not compare strings, it compares a "magic" sum (from Namestring) with another magic sum (from Numberstring). And: * SUMS magics inside the GDI, not inside its own code; * USES a look_up table for input validation instead of "plain" code; * COMPARES the "magic" manipulation from input NUMBER with the "magic" manipulation from input NAME. The cracking procedure for most of these windows programs is pretty simple and relatively straightforward: 1) SEE THE NAME OF YOUR BABE AND ITS QUEUE SELECTOR :task ;This is the Winice95 command you type after firing snap32 and getting at the "Enter License" nag window: TaskName SS:SP StckTp StckBt StckLw TaskDB Hqueue Events Snap32 0000:0000 006 AC000 006B0000 270E D27 0000 OK, the babe is Snap32,it's HQUEUE is 0xD27, it's TaskDB is 0x27OE, orright. 2) SEE THE MODULES OF YOUR BABE: :map32 snap32 ;Your command Owner Obj Name Obj# Address Size Type SNAP32 .text 0001 0137:00401000 00043000 CODE RO SNAP32 .rdata 0002 013F:00444000 00002E00 IDATA RO SNAP32 .data 0003 013F:00447000 00009000 IDATA RW SNAP32 .idata 0004 013F:00471000 00001C00 IDATA RW SNAP32 .rsrc 0005 013F:00473000 00001600 IDATA RO SNAP32 .reloc 0006 013F:00475000 00004C00 IDATA RO OK, so the code is in selector 137:(as usual), and you have there 43000 bytes of code from 401000 to 401000+43000; the DATA, ReadWrite and ReadOnly, are in selector 13F: (as usual). 3) SEE THE HANDLE OF THE PROTECTION "NAG" WINDOW :hwnd snap32 ;Your command Window Handle Hqueue SZ Qowner Class Name Window Procedure 0350(1) 0D27 32 SNAP32 #02071 144F:0560 0354(2) 0D27 32 SNAP32 #02071 17CF:102E ... and many more windows that we do not care of. OK, so, for our cracking purposes, it's Handle 0x350. Most of the times the "nag" window you want to crack will be the first one in the hwnd listing (coz it was the last one to appear). Watch the number in parentheses that follows the Whandle: (1) is a mother, (2) are "children" windows. At times you'll find under "Class Name" something like "Edit" (see before the Winformant cracking)... SNIFF THERE! At times the "Window Procedure" code location in a list of more than twenty, will be slightly different for one or two windows... SNIFF THERE! 4) BREAKPOINT MESSAGE WM_GETTEXT (or any other WM_ that you can think of in order to "pinpoint" the code of our babe). "Pinpointing" the code is extremely important in windows cracking... this idiotic OS moves code, data and stack out and inside the pages all the time... so you'll keep getting on "INVALID" sections without a correct pinpointing. Good Pinpointing points are in general: BMSG xxxx WM_GETTEXT (good for passwords) BMSG xxxx WM_COMMAND (good fro OK buttons) BPRW *your babe* TW (good for tracking) u USER!GETWINDOWTEXT (u and then BPX inside the code) u GETDLGITEM (for the Hwnd of an Item inside a Dialog Box) CSIP NOT GDI (if you have too many interferences) u USER!SHOWWINDOW (bpx with counter occurrence to get to the "right" window) u GETSYSTEMTIME (for "time-crippled" software) and many others pinpointing points you'll learn. If you are really desperate for pinpointing, just do a BMSG xxxx WM_MOVE and then move the nag window, this will always work. Let's go on: :bmsg 350 wm_gettext ;Your command OK, so the code is ready to be pinpointed. 5)RUN THE PROGRAM TO THE BREAKPOINT: CTRL+D ;Your command to exit Winice and run until it pops out at breakpoint OK, now you pop out inside Winice somewhere... (look at the stack to know where) so the code has been pinpointed. 6) SEARCH THE DATA AREA for your input string (4 Gigabytes from 30:0... remember that DATA are *always* in 30:0 to 30:FFFFFFFF and CODE is *always* in 28:0 to 28:FFFFFFFF). In most protection the "registration_number" string must match the "username" string, which cannot be constrained, in order to allow users to choose whatever stupid name they fancy. Some protections requires fixed symbols inside the "username" string, though... in these rare eventualities, just apply to the "username" string what we'll do here with the "registration_number" string. The point to remember is: begin always with the protection fumbling your number, crack only if necessary the protection that fumbles your name. Let's search now. :s 30:0 lffffffff '12121212' ;Your command Pattern Found at 0030:80308612 80000000 is good. Lower era videos, mirrors and BIOS, higher (around C0000000) you have the OS dustbins... the point to remember is: investigate always FIRST the 80000000 locations. 7) BREAKPOINT ON MEMORY RANGE ON THIS STRING. By the way: prepare a watch window dex 3 es:di, you'll soon see how useful such an automated watchwindow is in password cracking. :bpr 30:80308612 30:80308612+8 RW ;Your command OK Now we'll begin to dig out the relevant parts of the code. Remember that you must breakpoint *every* copy of the string that protection generates. A typical copy routine, very frequently used in windows copy protection schemes, dwells inside KERNEL!HMEMCPY (+0076): 0117:9E8E 66C1E902 SHR ECX,02 0117:9E92 F36766A5 REPZ MOVSD ;makes a copy in es:di 0117:9E96 6659 POP ECX 0117:9E98 6683E103 AND ECX,+03 0117:9E9C F367A4 REPZ MOVSB 0117:9E9F 33D2 XOR DX,DX In fact, this piece of copying code is so often used for password verifications that sometimes you just need to bpx on 0117:9E92 to get the correct stack sequence... but let's, for now, continue without such little tricks: just keep on BPRring (Breakpoint on memory range) all copies that protection makes. 8) LET THE BABE RUN, it will breakpoint on all manipulations of your input string. One of them will lead to the magic. 8.1.) VALIDATION phase There are many routines that check and "validate" your inputs. The most common ones check that your numbers ARE really numbers, i.e. in the range 0x30-0x39. Usually this is done with: CMP EAX,+30 JB no_number CMP EAX,+39 JA no_number At times the protectionists use TABLES instead... The number itself is used as a pointer to a "ready made" table where the relevant magic can be used as a protection. Imagine that a number 4 in your input points to a code section that throws you immediately outside the validation routine... or imagine that a number 7, if found in your input, fetches a magic code that removes the whole program from your harddisk (or worse): "Ah, ah! Stupid cracker will never know that he should not have used number 4... and definitely not number 7! Next time he'll learn..." Yes, tables have been used for such nasty tricks. Here the relevant code for the "validation" part of our protection (still checking my favourite input string '12121212'): :check_if_valid 0137:4364AE 8A16 MOV DL,[ESI] ;load license number 0137:4364B0 33C0 XOR EAX,EAX ;zero AX 0137:4364B2 668B0451 MOV AX,[ECX+2*EDX] ;look table for 84 0137:4364B6 83E008 AND EAX,+08 ;OK if AND'S TO zero 0137:4364B9 85C0 TEST EAX,EAX ;and therefore 0137:4364BB 7403 JZ 004364C0 ;go on 0137:4364BD 46 INC ESI ; ready for next number 0137:4364BE EBCD JMP 0043648D :strip_-_&_+_signs 0137:4364C0 33DB XOR EBX,EBX ;clean BX 0137:4364C2 8A1E MOV BL,[ESI] ;load license number 0137:4364C4 46 INC ESI ;ready for next 0137:4364C5 8BFB MOV EDI,EBX ;save copy 0137:4364C7 83FB2D CMP EBX,+2D ;is it a "-"? 0137:4364CA 7405 JZ 004364D1 0137:4364CC 83FB2B CMP EBX,+2B ;is it a "+"? 8.2.) MANIPULATION (summing magic numbers) Your wisely set breakpoints on memory range for the occurrence of the string "12121212" will pop you out, inter alia, inside following piece of code (note how this part of protection dwells inside GDI, and NOT inside the code selector of snap32): 0557:11BD 33C0 XOR EAX,EAX ;zero AX 0557:11BF 66648B06 MOV AX,FS:[ESI] ;load number 0557:11C3 83C602 ADD ESI,+02 ;point to next 0557:11C6 66833C4700 CMP WORD PTR [EDI+2*EAX],+00 0557:11CB 0F8424010000 JE 000012F5 0557:11D1 668B0442 MOV AX,[EDX+2*EAX] ;load from magic table 0557:11D5 03D8 ADD EBX,EAX ;save sum in EBX 0557:11D7 49 DEC ECX ;till we are done 0557:11D8 75E5 JNZ 000011BF ;loop along Interesting, isn't it? Protection is using this GDI routine to create a SUM (through pointers to another table) that depends on your very input numbers. We are now very near to the crack... can you *feel* it? If not, prepare yourself a good Martini Vodka! This is the correct way to do it: * Get a "highball" glass; * Put some ice cubes inside it (2 or 3); * Add Martini Dry (From Martini & Rossi). Fill to 1/3; * Add Moskowskaja Wodka (the only real Vodka). Fill to 2/3; * Add a zest of lemon (From Malta or Southern France); * Add a green "sound" olive (from Italy or Israel); * Add Schweppes Indian Tonic. Fill to the brim. Sit deeper and relax, sip slowly and *feel* where the code of the protection scheme you are cracking "moves"... It's like a current... a slow tide. If you still do not believe me, just try it. We'll now find out where protection stores the "magic" sum (and now you'll pop out inside the very own snap32 code, this is the "real" protection part): 8.3.) The ludicrous "HIDING" of the magic sum 0137:40437E 83C404 ADD ESP,+04 0137:404381 8B4DE8 MOV ECX,[EBP-18] 0137:404384 8945F0 MOV [EBP-10],EAX ;***HERE!*** 0137:404387 68FF000000 PUSH 000000FF 0137:40438C 8D8574FBFFFF LEA EAX,[EBP+FFFFFB74] ;load string 0137:404392 50 PUSH EAX ;push it 0137:404393 E886410100 CALL 0041851E ;manipulate 0137:404398 8D8574FBFFFF LEA EAX,[EBP+FFFFFB74] ;load string 0137:40439E 50 PUSH EAX ;push it 0137:40439F E88C210300 CALL 00436530 ;manipulate As you can see, the protection is very simple: The "magic" sum is hidden only two lines before the further manipulations of the input string. We have found location 137:404384, here, in the CORRECT way, through bprring of the string that has been manipulated in the GDI, but actually, we could have found it quickly just checking superficially what's happening "around" all manipulations of the input string. Do we really need to follow all manipulations of our registration_number and eventually also all manipulation of our username? NO, not at all: we just set a BPR on the stack location where protection hides the sum [EBP-10] and we'll see what happens: 90% of these protections just create two sums, a sum from your username and a sum from your registration_number... somewhere there will be a compare that must use this location (or a copy of it... we'll see). 8.4.) COMPARING THE MAGICS FROM THE TWO INPUT STRING Breakpoint on memory range on the sum location [EBP-10] that you saw in the previous code and you'll land at this piece of code: 0137:404412 E82F050000 CALL 00404946 0137:404417 83C40C ADD ESP,+0C 0137:40441A 3B45F0 CMP EAX,[EBP-10] ;comp AX & magicsum 0137:40441D 740F JZ 0040442E 0137:40441F 68C0874400 PUSH 004487C0 0137:404424 E8149E0000 CALL 0040E23D 0137:404429 83C404 ADD ESP,+04 0137:40442C EB5B JMP 00404489 0137:40442E 893DA0714400 MOV [004471A0],EDI 0137:404434 85FF TEST EDI,EDI That's it, you have made it! We found the compare between the "username" magic number (for my "+ORC+ORC" string that's here 0x7C25621B) in AX (we do not need to know how this landed there... it's irrelevant!) and the "license_number" '12121212' (whose magic is here 0x00B8F47C) stored in [pointer-10.] How do we find now the correct INPUT number for +ORC+ORC? Well, it's easy... the "magic number" must be the same... therefore: Cracked=Dec(0x7C25621B) Cracked=2082824731 That was it. Old Snap32 has been cracked. You could now prepare a crack in order to distribute this program around without its simple protection. Good cracked applications should be given free (i.e. cracked) to all the people that NEED them and do not have the money to buy them. Don't forget that in this intolerable society the 0,5% of the citizens own the 56% of the industrial capital and the 63% of the propaganda machines (data from US researchers... therefore suspect... the real situation is probably even worser) effectively conditioning the destiny of millions of slaves, moronized by television watching. So crack the applications and give them to the people you care and the peolple that need them, but for the others... just EXPLAIN everybody how you did it... this is real help: giving knowledge, not wares. DO NOT use my handle and my codes to crack this program, get yours, I gave you mine only as an help for this cracking lesson. I have showed you the way enough... THIEFS, not crackers, use the codes that others have found. You are (gonna be) CRACKERS! Remember it, look straight ahead, crack accurately and keep your tommy in. HOW TO SEARCH THE INTERNET FOR FILES WITHOUT MOVING A FINGER It's amazing: most of the people roaming around inside Internet DO NOT know how to use effectively the web. I'll be very altruistic and explain how to fetch the very example of Snap32, the babe we cracked in this lesson. 1) Choose an archie from this list (I will not explain you what an archie is, you should know it... if you do not, be ashamed): archie.univie.ac.at 131.130.1.23 Austria archie.belnet.be 193.190.248.18 Belgium archie.funet.fi 128.214.6.102 Finland archie.univ-rennes1.fr 129.20.254.2 France archie.th-darmstadt.de 130.83.22.1 Germany archie.ac.il 132.65.16.8 Israel archie.unipi.it 131.114.21.10 Italy archie.uninett.no 128.39.2.20 Norway 2) Email a message to your archie: To: archie.univie.ac.at (for instance) Subject: (nothing on this field) Body: set search sub (substrings too) set maxhits 140 (max 140 hits) set maxhitspm 9 (not the same file all over) find snap32 (we want this) 3) After a while you'll get (per email) your answer: Here the answer from the Austrian archie Host ftp.wu-wien.ac.at (137.208.8.6) Last updated 17:48 9 Aug 1995 Location: /pub/systems/windows.32/misc FILE -rw-r----- 128957 bytes 15:59 16 Jun 1995 snap32.zip Host space.mit.edu (18.75.0.10) Last updated 00:45 4 Mar 1996 Location: /pub/mydir FILE -rw-r--r-- 407040 bytes 11:55 28 Nov 1995 snap32.exe 4) ftpmail your file (Browsing is no good: too busy and lame). Again, I will not explain you what an FTPMAIL server is: learn it by yourself... choose a good one from this list (there are many more... you'll learn): bitftp@vm.gmd.de (Germany) ftpmail@ieunet.ie (Ireland) bitftp@plearn.edu.pl (Poland) ftpmail@ftp.sun.ac.za (South Africa) ftpmail@ftp.sunet.se (Sweden) ftpmail@ftp.luth.se (Sweden) ftpmail@src.doc.ic.ac.uk (United Kingdom) To: ftpmail@ftp.sun.ac.za. (for instance) Subject: (leave blank) Body: open space.mit.edu (the last occurrence that the archie sent) cd/pub/mydir (get the correct subdir) bin (prepare for BINARY) get snap32.exe (I want this) quit (bye) 5) Your FTPMAIL server will first notice you a receipt: FTP EMAIL response... ftpmail has received the following job from you: reply-to +ORC open space.mit.edu +ORC@now.here get snap32.exe ftpmail has queued your job as: 1834131821.5514 Your priority is 1 (0 = highest, 9 = lowest) Requests to sunsite.doc.ic.ac.uk will be done before other jobs. There are 14 jobs ahead of this one in the queue. 4 ftpmail handlers available. To remove send a message to ftpmail containing just: delete 1834131821.5514 After a while you'll get a second message, with your file uuencoded inside... everything has been done. YESSIR! there is absolutely no need to loose time on the WWW, "surfing" idiotically from a junk site to the next or waiting hours to download some slow file from an instable server! Wasting time of your own LIFE, that you could use to read poetry, to make love, to look at the stars, to sail slowly between the Aegean islands or to start a nice cracking session. What's the point of wasting your time when machines can perform all the searches you need better, more productively and faster than you ever could... YESSIR! You can get *everything* on the Web, and without paying your Internet provider more than a couple of dimes... Nice, isn't it? By now, if you have followed all my lessons, you should be able to crack relatively quickly "normal" applications. There are some new projects for 1997: a cracking "university", that will allow us to prepare for the divine war against Microsoft repulsive dominion. If you do not have already chosen your handle (your "cracker" name, that's it), you may consider choosing an handle with a "+" somewhere inside it or, eventually, add a "+" to your handle. This sign is used by me and by friends that have studied and/or contributed. But a "+" in your handle ("official +ORC cracker") will mean even more: 1) allows support from me personally (on a "do ut des" basis) 2) allows pupils to identify each other (good for joining forces) 3) will open you (eventually) the doors to the "higher" cracking university I'll set up on the Web in 1997. (I'm not getting megalomaniac... In reality I only need a "quick" method to know on which (anonymous) people I can count on for the next phase). Well, that's it for this lesson, reader. Not all lessons of my tutorial are on the Web. You 'll obtain the missing lessons IF AND ONLY IF you mail me back (via anon.penet.fi) with some tricks of the trade I may not know that YOU discovered. Mostly I'll actually know them already, but if they are really new you'll be given full credit, and even if they are not, should I judge that you "rediscovered" them with your work, or that you actually did good work on them, I'll send you the remaining lessons nevertheless. Your suggestions and critics on the whole crap I wrote are also welcomed. E-mail +ORC +ORC an526164@anon.penet.fi HOW TO CRACK, by +ORC, A TUTORIAL --------------------------------------------------------------------------- Lesson A.1: Advanced Cracking: Internet Cracking (Unix) --------------------------------------------------------------------------- -------------> INTERNET CRACKING: FIREWALLS With each new company that connects to the "Information Superhighway" new frontiers are created for crackers to explore. Site administrators (Siteads) have implemented various security measures to protect their internal networks. One of these is xinetd, covered later. A more general solution is to construct a guarded gateway, called a [Firewall], that sits between a site's internal network and the wild and woolly Internet where we roam. In fact only one third of all Internet connected machines are already behind firewalls. Most information services have to deal with the same problem we have: getting OUT through a local firewall or GETTING INTO a service through their Firewall. There lays also the crack_solution. ------------> What is a Firewall? The main purpose of a Firewall is to prevent unauthorized access between networks. Generally this means protecting a site's inner network from the Internet. If a site has a firewall, decisions have been made as to what is allowed and disallowed across the firewall. These decisions are always different and always incomplete, given the multiplicity of Internet, there are always loopholes where a cracker can capitalize on. A firewall basically works by examining the IP packets that travel between the server and the client. This provides a way to control the information flow for each service by IP address, by port and in each direction. A firewall embodies a "stance". The stance of a firewall describes the trade-off between security and ease-of-use. A stance of the form "that which is not expressly permitted is prohibited" requires that each new service be enabled individually and is seldom used, coz very slow and annoying. Conversely, the stance "that which is not expressly prohibited is permitted" has traded a level of security for convenience. It will be useful to guess the stance of the firewall you are cracking when making probe decisions. A firewall has some general responsibilities: * First and foremost if a particular action is not allowed by the policy of the site, the firewall must make sure that all attempts to perform the action will fail. * The firewall should log suspicious events * The firewall should alert internal administration of all cracking attempts * Some firewall provide usage statistics as well. ------------> Types of Firewall In order to avoid head-scratching, it's a good idea to know the TOPOLOGY of "your" firewall -and its limitations- before attempting to get through it. Discussed below are two popular firewall topologies. Although other types exist, the two below represent the basic forms; most other firewalls employ the same concepts and thus have -luckily- the same limitations. 1) THE DUAL-HOMED GATEWAY A dual-homed Gateway is a firewall composed of a single system with at least two network interfaces. This system is normally configured such that packets are not directly routed from one network (the Internet) to the other (the internal net you want to crack). Machines on the Internet can talk to the gateway, as can machines on the internal network, but direct traffic between nets is blocked. In discussing firewalls, it's generally accepted that you should think of the inner network as a medieval castle. The "bastions" of a castle are the critical points where defence is concentrated. In a dual-homed gateway topology, the dual-homed host itself is called the [BASTION HOST]. The main disadvantage of a dual-homed gateway, from the viewpoints of the users of the network and us crackers alike, is the fact that it blocks direct IP traffic in both directions. Any programs running on the inner network that require a routed path to external machines will not function in this environment. The services on the internal network don't have a routed path to the clients outside. To resolve these difficulties, dual-homed gateways run programs called [PROXIES] to forward application packets between nets. A proxy controls the conversation between client and server processes in a firewalled environment. Rather than communicating directly, the client and the server both talk to the proxy, which is usually running on the bastion host itself. Normally the proxy is transparent to the users. A proxy on the bastion host does not just allow free rein for certain services. Most proxy software can be configured to allow or deny forwarding based on source or destination addresses or ports. Proxies may also require authentication of the requester using encryption- or password-based systems. The use of proxy software on the bastion host means that the firewall administrator has to provide replacements for the standard networking clients, a nightmare in heterogeneous environments (sites with many different operating systems platforms, PC, Sun, IBM, DEC, HP...) and a great burden for administrator and users alike. 2) THE SCREENED HOST GATEWAY A screened host gateway is a firewall consisting of at least one router and a bastion host with a single network interface. The router is typically configured to block (screen) all traffic to the internal net such that the bastion host is the only machine that can be reached from the outside. Unlike the dual- homed gateway, a screened host gateway does not necessarily force all traffic through the bastion host; through configuration of the screening router, it's possible to open "holes" in the firewall to the other machines on the internal net you want to get into. The bastion host in a screened host firewall is protected from the outside net by the screening router. The router is generally configured to only allow traffic FROM SPECIFIC PORTS on the bastion host. Further, it may allow that traffic only FROM SPECIFIC EXTERNAL HOSTS. For example the router may allow Usenet news traffic to reach the bastion host ONLY if the traffic originated from the site's news provider. This filtering can be easily cracked: it is relying on the IP address of a remote machine, which can be forged. Most sites configure their router such that any connection (or a set of allowed connections) initiated from the inside net is allowed to pass. This is done by examining the SYN and ACK bits of TCP packets. The "start of connection" packet will have both bits set. If this packets source address is internal... or seems to be internal :=) the packet is allowed to pass. This allows users on the internal net to communicate with the internet without a proxy service. As mentioned, this design also allows "holes" to be opened in the firewall for machines on the internal net. In this case you can crack not only the bastion host, but also the inner machine offering the service. Mostly this or these machine/s will be far less secure than the bastion host. New services, for instance recent WEB services, contain a lot of back doors and bugs, that you'll find in the appropriate usenet discussion groups, and that you could use at freedom to crack inner machines with firewall holes. Sendmail is a good example of how you could crack in this way, read the whole related history... very instructive. The rule of thumb is "big is good": the bigger the software package, the more chance that we can find some security related bugs... and all packages are huge nowadays, 'coz the lazy bunch of programmers uses overbloated, buggy and fatty languages like Visual Basic or Delphy! Finally, remember that the logs are 'mostly) not on the bastion host! Most administrators collect them on an internal machine not accessible from the Internet. An automated process scan the logs regularly and reports suspicious information. 3) OTHER FIREWALL TOPOLOGIES The dual-homed gateway and the screened host are probably the most popular, but by no mean the only firewall topologies. Other configurations include the simple screening router (no bastion host), the screened subnet (two screening routers and a bastion host) as well as many commercial vendor solutions. ------------> Which software should we study? Three popular unix software solutions allow clients inside a firewall to communicate with server outside: CERN Web server in proxy mode, SOCKS and the TIS Firewall toolkit. 1) The CERN Web server handles not only HTTP but also the other protocols that Web clients use and makes the remote connections, passing the information back to the client transparently. X-based Mosaic can be configured for proxy mode simply by setting a few environment variables. 2) The SOCKS package (available free for anonymous ftp from ftp.nec.com in the file /pub/security/socks.cstc/socks.cstc.4.2.tar.gz includes a proxy server that runs on the bastion host of a firewall. The package includes replacements for standard IP socket calls such as connect(), getsockname(), bind(), accept(), listen() and select(). In the package there is a library which can be used to SOCKSify your crack probes. 3) The Firewall Toolkit The toolkit contains many useful tools for cracking firewall and proxy server. netacl can be used in inetd.conf to conceal incoming requests against an access table before spawning ftpd, httpd or other inetd-capable daemons. Mail will be stored in a chroot()ed area of the bastion for processing (mostly by sendmail). The Firewall toolkit is available for free, in anonymous ftp from ftp.tis.com in the file /pub/firewalls/toolkit/fwtk.tar.Z The popular PC firewall solution is the "PC Socks Pack", for MS- Windows, available from ftp.nec.com It includes a winsock.dll file. The cracking attempts should concentrate on ftpd, normally located on the bastion host. It's a huge application, necessary to allow anonymous ftp on and from the inner net, and full of bugs and back doors. Normally, on the bastion host, ftpd is located in a chroot()ed area and runs as nonprivileged user. If the protection is run from an internal machine (as opposing the bastion host), you could take advantage of the special inner-net privileges in hostp.equiv or .rhosts. If the internal machine "trusts" the server machine, you'll be in pretty easily. Another good method, that really works, is to locate your PC physically somewhere along the route between network and archie server and "spoof" the firewall into believing that you are the archie server. You'll need the help of a fellow hacker for this, though. Remember that if you gain supervisor privileges on a machine you can send packets from port 20, and that in a screened host environment, unless FTP is being used in proxy mode, the access filters allow often connections from any external host if the source port is 20 and the destination port is greater than 1023! remember that NCSA Mosaic uses several protocols, each on a different port, and that -if on the firewall no proxy Web server is operating- each protocol must be dealt with individually, what lazy administrators seldom do. Be careful for TRAPS: networking clients like telnet and ftp are often viciously replaced with programs that APPEAR to execute like their namesake, but actually email an administrator. A fellow cracker was almost intercepted, once, by a command that simulated network delays and spat out random error messages in order to keep me interested long enough to catch me. Read the (fictions) horror story from Bill Cheswick: "An evening with Berferd in which a cracked is lured, endured and studied", available from ftp.research.att.com in /dist/internet_security/berferd.ps As usual, all kind of traps can be located and uncovered by correct zen-cracking: you must *FEEL* that some code (or that some software behaviour) is not "genuine". Hope you believe me and learn it before attempting this kind of cracks. ------------> How do I crack Firewalls? Some suggestions have been given above, but teaching you how to crack firewalls would take at least six complete tutorial lessons for a relatively unimportant cracking sector, and you would almost surely get snatched immediately, 'coz you would believe you can crack it without knowing nothing at all. So, for your sake, I'll teach you HOW TO LEARN IT, not HOW TO DO IT (quite a fascinating difference): First Text, then the software above. For text, start with Marcus Ranum's paper "Thinking about Firewalls", available from ftp.tis.com in the file/pub/firewalls/firewalls.ps.Z and do an archie search for newer literature. Join the firewall discussion list sending a message to majordomo@greatcircle.com, you'll get a message with instructions, as usual, lurk only... never show yourself to the others. You can find for free on the web quite a lot of early versions of proxy software. Study it, study it and then study it again. The cracking efforts on your copies, and your machines, before attempting anything serious, are MANDATORY if you do not want to be immediately busted on the Internet. When you feel ready to try serious cracking, you must OBLIGATORY start with a small BBS which uses a firewall version you already studied very well (sysops are not firewall administrators, and many of them do not know nothing about the software they use). As soon as you gain access to the bastion host, remember to subvert entirely the firewall itself before entering the inner net. If you feel ready and everything went well so far, if your zen- cracking abilities are working well... then take a moment for yourself... prepare yourself a good Martini-Wodka (you should only use Moskovskaia), take a deep breath and by all means go ahead! You will then be able to try your luck on the Cyberspace and get quickly busted (if you did not follow my admonitions and if you cannot zen-crack) or, may be, fish quite a lot of jewels... :=) -------------> INTERNET CRACKING: XINETD [Xinetd] a freely available enhanced replacement for the internet service daemon inetd, allows just those particular users to have FTP or Telnet access, without opening up access to the world. Xinetd can only protect the system from intrusion by controlling INITIAL access to most system services and by logging activities so that you can detect break-in attempts. However, once a connection has been allowed to a service, xinetd is out of the picture. It cannot protect against a server program that has security problems internally. For example, the finger server had a bug several years ago that allowed a particularly clever person to overwrite part of its memory. This was used to gain access to many systems. Even placing finger under the control of xinetd wouldn't have helped. Think of the secured firewall system as a fortress wall: each service that is enabled for incoming connections can be viewed as a door or window in the walls. Not all these doors have secure and reliable locks. The more openings are available, the more opportunities are open for us. -------------> What xinetd does Xinetd listens to all enabled service ports and permits only those incoming connection request that meet authorization criteria. - Accept connections from only certain IP addresses - Accept connections only from authorized users - Reject connections outside of aithorized hours - Log selected service when connections are accepted or rejected, capturing following informations: * Remote Host Address * User ID of remote user (in some cases) * Entry and Exit time * Terminal type Support login, shell, exec and finger -------------> SERVICES TO CRACK & UNWITTING INSIDE COMPLICES In this order the easy services: FTP TELNET LOGIN (rlogin) SHELL (rcmd) EXEC In this order the more difficult ones: MOUNT TFT FINGER NFS(Network File System) DNS(Domain Name Service) Remember that sendmail (SMTP), by default, accepts a message from any incoming connection. The "sender" of such a message can appear to have originated anywhere, therefore your claim of identity will be accepted! Thus you can forge a message's originator. Most of the recipients inside the protected (firewalled) net will take your claim at face value and send you (to the "return address" you provide) all the sensitive information you need to crack the system. Finding unwitting inside complices is most of the time pretty easy. By far the best method, for entering xinetd, is to get the real version from panos@cs.colorado.edu, modify the system files in order to have some backdoors, and then distribute them to the mirror servers on the WEB. Each time a new administrator will download "your" version of xinetd, you'll have an easy access to the "protected" system. On the Nets, it's important to conceal your identity (they will find you out pretty quickly if you do not). The best method is to obtain the IP address of a legitimate workstation during normal hours. Then, late at night, when the workstation is known to be powered-off or disconnected from a dialup PPP link, a different node on the network can be configured to use the counterfeit IP address. To everyone on the network, it will appear that the "legitimate" user is active. If you follow this strategy, you may want to crack somehow more negligently... the search for the cracker will go on -later- in the false confidence that a sloppy novice (the legitimate user) is at work, this will muddle the waters a little more. Well, that's it for this lesson, reader. Not all lessons of my tutorial are on the Web. You 'll obtain the missing lessons IF AND ONLY IF you mail me back (via anon.penet.fi) with some tricks of the trade I may not know that YOU discovered. Mostly I'll actually know them already, but if they are really new you'll be given full credit, and even if they are not, should I judge that you "rediscovered" them with your work, or that you actually did good work on them, I'll send you the remaining lessons nevertheless. Your suggestions and critics on the whole crap I wrote are also welcomed. E-mail +ORC +ORC an526164@anon.penet.fi HOW TO CRACK, by +ORC, A TUTORIAL --------------------------------------------------------------------------- LESSON C (1) - How to crack, Cracking as an art --------------------------------------------------------------------------- [BARCODES] [INSTANT ACCESS] -------------------------------------- [BARCODES] First of all, let me stress the importance of cracking in our everyday life. Cracking it's not just about software, it's about information, about all patterns of life. To crack is to refuse to be controlled and used by others, to crack is to be free. But you must also be yourself free from petty conventions in order to crack properly. You must learn to discerne cracking possibilities all around yourself, and believe me, the development of this ghastly society brings every day new codes, protections and concealing mechanismes. All around us grows a world of codes and secret and not so secret patterns. Codes that are at times so familiar and common that we do not even notice them any more... and yet they are there to fool us, and yet they offer marvellous cracking possibilities. Let's take as an striking example BARCODES... those little lines that you see on any book you buy, on any bottle you get, on any item around you... do you know how they work? If you do not you may be excused, but you cannot be excused if you never had the impulse to understand them... crackers are curious by nature... heirs of an almost extinct race of researchers that has nothing in common with the television slaves and the publicity and trend zombies around us. Cracker should always be capable of going beyond the obvious, seek knowledge where others do not see and do not venture. [BARCODE HISTORY] Let's begin with a little history. Universal Product Code (UPC) was adopted for commercial use by the grocery industry in the USA. Among the advantages were a rapid, accurate and reliable way of entering stock information into a computer and the possibility to sack a lot of workers and to do more profit. The early success led to the development of the European Article Numbering System (EAN), a symbology similar to UPC, that is widely used in Europe and in the rest of the World. I'll teach you to crack this one, since I do not -fortunately- live in the States. Keep in mind, anyway, that there are different barcode symbologies, each with its own particular pattern of bars. The UPC/EAN code used on retail products is an all-numeric code; so is the Interleaved 2 of 5 Code. Code 39 includes upper case letters, digits, and a few symbols. Code 128 includes every printable and unprintable ASCII character code. The most new one is a 2-D code. These are special rectangular codes, called stacked barcodes or matrix codes. They can store considerably more information than a standard barcode. They require special readers which cost more than a standard scanner. The practical limit for a standard barcode depends on a number of factors, but 20 to 25 characters is an approximate maximum. For applications that need more data, matrix codes are used. For example, the next time you receive a package from United Parcel Service look for a small square label with a pattern of dots and a small bullseye in the centre. This is a MaxiCode label, and it is used by UPS for automatic destination sortition. The manufacturer's ID number on the barcode uniquely identifies products. These numbers are managed by the Uniform Code Council in Dayton, Ohio for the States and Canada and by the EAN authority (Internationale Article Numbering Association) in Bruxelles, for Europe and the rest of the World. The manufacturer's ID number accounts for some digits of the code, which leaves other digits to be assigned in any way the producer wants. He provides retail outlets with a list of his products and their assigned codes so that they can be entered in the cash register system. Many codes are NOT on the products and are added by the supermarkets on the fly, using an internal code schema that may be non standard. Now it's enough... let's crack. BARCODES are the only thing an automated casher needs to see on a product to calculate its price and automatically catalogate the sold merchandise... imagine (just imagine it :=) coz it would be extremely illegal to act in this way) somebody would fasten an adhesive home-made codebar label direct on the top of the supermarket/mall/retail store label, say on a bottle of Pomerol (that's a very good but unfortunately very expensive french wine). The new label would mean for the casher something like "cheap wine from Bordeaux, France, cost so and so, everything it's OK, do not worry"... do you think that anybody would come to the idea that there is something wrong with the label, with the bottle or with you? I have been codebaring for years and had only once a problem, coz my printer was running out of ink and the scanner in the supermarket could not read it... so what? Act uninterested, always wear jackets of the utmost quality, shetland pullovers and beautiful expensive shoes... (all articles that you may codebar too, by the way), in this society appearance and look count much more than substance and knowledge... LET'S USE THIS TO OUR ADVANTAGE! Nobody will ever come to the idea that you may actually really know the working of the scheme... coz codebar is pretty complicated and not exactly exceptionally public. On the Web there are a lot information about it, but most of them are useless, unless you know how to search most of the time you'll find only sentences like this one: "The calculated check digit is the twelfth and final digit in the U.P.C.code. It is calculated based on a specific algorithm, and is necessary to ensure that the number is read or key-entered correctly." But good +ORC will now explain you everything you need to crack: [THE 13 BAR "CODES"] Each barcode label has 13 values, from #0 to #12 (that's the EAN code, the UPC american one has only 12, from #0 to #11). #0 and #1 indicate the origin of the product. #2 to #11 give the article code #12 (the last and 13th one) is a checksum value, that verifies the validity of all the other numbers. How is it calculated? #12 is calculated in 4 steps VALUE A: You sum odd position numbers (#0+#2+#4+#6+#8+#10) VALUE B: You sum even position numbers and multiply by 3 ((#1+#3+#5+#7+#9+#11)*3) VALUE C: You sum value A and value B VALUE D: You mod value C (you divide by 10 and only keep the remaining units, a very widespread checking scheme as you'll see in the software part of this lesson) If the result is not zero, you subtract it from 10. Now look at a barcode label, get some books or other barcoded items and *watch* it... Bar codes are supposed to have "quiet zones" on either side of the symbol. Quiet zones are blank areas, free of any printing or marks,typically 10 times the width of the narrowest bar or space in the bar code. Failure to allow adequate space on either side of the symbol for quiet zones can make it impossible to read the bar code. On the barcode there are two "borders", left and right, and a "middle" longer line. These three lines are longer than the others and are used to "regulate" the scanner to whatever dimension has been used for the barcode. #0 dwells left of the first (left) border and has a special meaning, the other 12 numbers are written "inside" the code and are divided in two "groups" by the middle bar. Each value is coded through SEVEN bars: black=1 and White=0. These form two couples of "optic" bars of different widths. We come now to the "magic" part: In order to bluff the simpletons, barcode uses three different SETS of characters to represent the values 0-9. This should make it impossible for you to understand what's going on, as usual, in this society, slaves should not need to worry with the real functioning of things. Here are the graphic codes of the three graphic sets: CODE A CODE B (XOR C) CODE C (NOT A) 0: 0001101 (13) 0100111 (39) 1110010 (114) 1: 0011001 (25) 0110011 (51) 1100110 (102) 2: 0010011 (19) 0011011 (27) 1101100 (108) 3: 0111101 (61) 0100001 (33) 1000010 (066) 4: 0100011 (35) 0011101 (29) 1011100 (092) 5: 0110001 (49) 0111001 (57) 1001110 (078) 6: 0101111 (47) 0000101 (05) 1010000 (080) 7: 0111011 (59) 0010001 (17) 1000100 (068) 8: 0110111 (55) 0001001 (09) 1001000 (072) 9: 0001011 (11) 0010111 (23) 1110100 (116) Borders: 101 Centre: 01010 - The C graphic set is a "NOT A" graphic set. - The B graphic set is a "XOR C" graphic set. - each value has two couples of bars with different widths Now watch some labels yourself... see the difference between the numbers left and the numbers right? The first "half" of the barcode is coded using sets A and B, the second "half" using set C. As if that were not enough, A and B are used inside the first "half" in a combination that varies and depends from value #0, following 10 different patterns: #1 #2 #3 #4 #5 #6 0 A A A A A A 1 A A B A B B 2 A A B B A B 3 A A B B B A 4 A B A A B B 5 A B B A A B 6 A B B B A A 7 A B A B A B 8 A B A B B A 9 A B B A B A "Ah! Stupid buyer will never understand why the same values gives different bars! Nothing is as reliable as barcodes!" :=) Let's take as example the codebar for Martini Dry: BARCODE: 8 0 00570 00425 7 Let's see: we have a 8 0 0 = booze Then a 000570 as ABABBA and a 004257 as C "Even" sum: 8+0+5+0+0+2 = 15 (even sum) Then a 0+0+7+0+4+5= 16 and 16 *3 = 48 (odd sum) Then a 15+48=63 63 === 3 10 - 3 = 7 = checksum Pattern = 8 = ABABBA CCCCCC OK, one more example: Osborne Windows programming series Volume 2 General purpose API functions (always here on my table)... BARCODE: 9 7 80078 81991 9 Let's see: we have a 9 7 8 = book Then a 780078 as ABBABA and a 819919 as C "Even" sum: 9+8+5+8+8+4 = 42 (even sum) Then a 7+1+5+2+4+4= 23 and 23 * 3 = 69 (odd sum) Then a 42+69=111 111 === 1 10 - 1 = 9 = checksum Pattern = 9 = ABBABA Well... what's the point of all this? The point, my pupils, is that who DOES NOT KNOW is taken along on a boat ride, who KNOWS and LEARNS can use his knowledge in order to try to beat blue and black the loathsome consumistic oligarchy where we are compelled to live. Try it out for yourself... if you crack correctly and wisely your supermarket, mall and library bills will be cut to almost zero. Write a small program to print whichever codebar you fancy (or whichever your mall uses) in whichever size on whichever sort of label you (or better your targets) fancy... it's quickly done with Visualbasic or Delphy... but you'll not find much on the Web Alternatively you could also write, as I did long ago, a short c program in dos, using a modified upper char set... and there you are, have labels... see the world. A small word of caution... crack only ONE item at time and try it out first with the SAME label for the same product... i.e. the correct code for that item, but on your own label. If it goes through your program works good, if not, nobody will ever be able to harm you. Anyway it never happens anything, never: the bar code reading equipments have great tolerance, coz the scanners must be able to recognize barcodes that have been printed on many different medias. You should choose labels similar to the ones effectively used only in order not to arise human suspects, coz for all the scanner itself cares, your label could be pink with green stripes and with orange hand-written, numbers. Mind you, we are still just academically imagining hypothetical situations, coz it would be extremely illegal to act in such an inconsiderate manner. CRACKING POWER! It's true for barcodes, for Telecom bills, for Compuserve accounts, for Amexco cards, for banking cheques (do you know what MICR is? Magnetic Ink Character Recognition... the stylized little printing on the lower left of new cheques... there is a whole cracking school working on it), for registration numbers... you name it, they develope it, we crack it... Begin with barcodes: it's easy, nice and pretty useful! Live in opulence, with the dignity and affluence that should always distinguish real crackers. Besides... you should see the assortment of 'Pomerols' in my "Cave-a-vin" :=) [INSTANT ACCESS] The (c) Instant access routines are a commercial protection scheme used to "unlock" complete commercial applications that have been encrypted on CD- ROMs which are distributed (mostly) through reviews. This is an ideal cracking target: it's commercial software, complete, uncrippled and of (relatively) prominent quality, that you can get in tons for the price of a coke. Obviously this kind of protection represents an ideal subject for our lessons. This fairly intricate protection scheme has not yet been cracked by anybody that I am aware of, anyway not publicly, therefore it's an ideal candidate for a "strainer" to my university. I'll teach you here how to crack it in three lessons, C.1, C.2 and C.3. I warn you... it's a difficult cracking session, and this protection represents quite an intellectual challenge. But if you are seriously interested in our trade you will enjoy these lessons more than anything else. This cracking is intended as an "assignment" for my +HCU "cracking university": you'll find inside lessons C.1 and C.2 a relatively deep "introduction" to Instant access cracking. This will teach you a lot anyway, and spare you hours of useless roaming around, bringing you straight to the cracking point. But I'll release the third part of this session, with the complete solution (lesson C.3) on the Web only in october 1996, not a day before. All the students that would like to apply to the Higher Cracking University, opening on the web 01/01/1997, should work in July, August and September (three months is more than enough time) on this assignment. They should crack completely the instant access scheme and send me their solutions, with a good documentation of their cracking sessions, before 30/09/1996 (WATCH IT! You can crack this scheme in -at least- three different paths, be careful and choose the *best* one. WATCH IT! Some of the informations) in lesson C.1 and C.2 are slightly incorrect: check it!). There are four possibilities: 1) The candidate has not found the crack or his solution is not enough documented or not enough viable... the candidate is therefore not (yet) crack-able, he will not be admitted to the +HCU 1997 curses, better luck in 1998; 2) The cracking solution proposed by the candidate is not as good as mine (you'll judge for yourself in october) but it works nevertheless... he'll be admitted at the 1997 courses; 3) The cracking solution of the candidate is more or less equal to mine, he'll be admitted, personally monitored, and he'll get all the material he needs to crack on higher paths; 4) The cracking solution of the candidate is better than mine, he'll be admitted, get all the material he wishes and asked to teach us as well as study with us: "homines, dum docent, discunt". [Cracking Instant access] The user that wants to "unlock" a software application protected with (c) Instant Access must enter first of all a REGISTRATION number string, which through a series of mathematical manipulations gives birth to a special "product" code. On the basis of this "product code" the user is asked to phone the commercial protectors (and pay) in order to get a special "unlock code" that will allow him to decrypt the relevant software. This kind of "passnumber" protection routines are widely used for software unlocking, BBS access, server access, backdoor opening and many other protection schemes. We have already seen password cracks in different lessons of this tutorial (in particular Lessons 3.1 and 3.2 for DOS and Lessons 8.1, 8.2 and 9.1 for WIN) albeit on a more simplistic scale: there it did mostly not matter very much *HOW* you passed the protection: once passed, you could have access to the application. This is not the case with (c) Instant Access. Face it: it's a little boring, but important that you learn how to defeat intricate protection routines (you'll meet them often in the next years) and I believe that the following example will give you a "feeling" for the right cracking approach. In this case we must not only "crack" this protection scheme but also study it thoroughly in order to achieve our blessed aims. This is a very good exercise: reverse disassembling will teach you a lot of little tricks that you'll be able to use in your other future cracking sessions. Instant access (c) is a exceptionally widespread protection scheme, and it should be relatively easy for you to gather some encrypted software that has been protected with this method... *DO IT QUICKLY!!* After the Web publishing of this lessons (I am sending C.1 to 8 pages and 4 usenet groups on 25/06/1996) this protection is obviously as dead as a Dodo. The "Accessors" guys will have to conceive something smarter if they want to keep selling "protections" to the lamer producers of "big" software. BTW, if you are reading this and are working for some commercial "protection" company, consider the possibility to double cross your masters! Deliver me anonymously all the future projects you are working on! That will amuse me, speed up the advent of a true altruistic society and earn you the respect of the better part of humanity. As I said, many "huge" application are still protected with this "Instant access" system. I have personally bought at least 7 or 8 "second hand" CD-ROMs packed full with Microsoft, Lotus, Norton, Symantec, you name it, applications all "protected" through this crap. The cost of this bunch of CD-ROMs was the equivalent of a bottle of Dry Martini, maybe less. The same software is sold, unlocked, to zombies and lusers for ludicrous amounts of money. Never buy CD-ROMs magazines when they appear! Be cool! Buy them two or three months after the publishing date! Buy "remainders" or "second hand" CD-ROM magazines "at kilo price"... Come to think of it, never buy *anything* when it appears or when some (paid) advertiser tells you to... remember that "trends", "vogues", "fashions" and "modes" are only different names for the whips that drill and chain the dull-witted slaves of this loathsome society: "clever crackers consider cool, crack cheap, cheat customary culture" (a rhetorical figure: an "Alliteration". To defend yourself learn rhetoric... it's a more powerful and more useful weapon than Kung-fu). The "triple" password protection routine in (c) Instant Access is very interesting from a cracker point of view. It's a relatively complex scheme: I'll teach you to crack it in two phases: First of all you must find the "allowed" registration code, the one that "ignites" the "product code". We must crack and understand this re_code first if we want to crack the rest. Just for the records, I am cracking here (c) Action Instant access version 1.0 (CD-ROM found on a old copy of "Personal Computer World" of August 1994, packed full with encrypted Lotus, Symantec, Claris and Wordperfect applications. Just to be sure I crosschecked my results with another CD-ROM which also has applications protected with (c) Instant Access: Paragon Publishing's PC OFFICE: the protection scheme remains the same). I am focusing for this lesson on the cracking of the specific protection for the encrypted Symantec's Norton Utilities v.8.0. Please refer to the previous lessons for the basic techniques used in order to find the protection routine inside our babe... for "low" cracking purposes you -basically- type a number (in this case, where the input gets 10 numbers, we'll use "1212-1212-12"), do your search inside the memory (s 30:0 lffffffff "your_string") and then set memory breakpoints on all the relevant memory locations till winice pops (I know, I know, buddies... there are more effective ways... but hold your mouth: for now we'll keep them among us: let's make things a little harder for the protectionists who read this... Besides: the old approach works here flawlessly). After getting the Registration window on screen the Winice standard procedure is: :task ; how :heap IABROWSE ; where & what :hwnd IABROWSE ; get the Winhandle :bpx [winhandle] WM_GETTEXT ; pinpoint code :bpx GetProcAddress ; in case of funny routines :dex 0 ds:dx ; let's see their name :gdt ; sniff the selectors :s 30:0 lffffffff "Your_input_string" ; search in 4 giga data :bpr [all memory ranges for your string that are above 80000000] and so on. (continued in lesson C.2) Well, that's it for this lesson, reader. Not all lessons of my tutorial are on the Web. You 'll obtain the missing lessons IF AND ONLY IF you mail me back (via anon.penet.fi) with some tricks of the trade I may not know that YOU discovered. Mostly I'll actually know them already, but if they are really new you'll be given full credit, and even if they are not, should I judge that you rediscovered them with your work, or that you actually did good work on them, I'll send you the remaining lessons nevertheless. Your suggestions and critics on the whole crap I wrote are also welcomed. E-mail +ORC +ORC an526164@anon.penet.fi HOW TO CRACK, by +ORC, A TUTORIAL --------------------------------------------------------------------------- LESSON C (2) - How to crack, Cracking as an art --------------------------------------------------------------------------- [INSTANT ACCESS] -------------------------------------- cracking Instant Access (2) - strainer for the +HCU [SEE LESSON C.1 for the first part of this cracking session] Here follow the relevant protection routines for the first (The "Registration") number_code of Instant Access, with my comments: you have to investigate a little the following code. Later, when you'll crack on your own, try to recognize the many routines that fiddle with input BEFORE the relevant (real protection) one. In this case, for instance, a routine checks the correctness of the numbers of your input: This_loop_checks_that_numbers_are_numbers: 1B0F:2B00 C45E06 LES BX,[BP+06] ; set/reset pointer 1B0F:2B03 03DF ADD BX,DI 1B0F:2B05 268A07 MOV AL,ES:[BX] ; get number 1B0F:2B08 8846FD MOV [BP-03],AL ; store 1B0F:2B0B 807EFD30 CMP BYTE PTR [BP-03],30 1B0F:2B0F 7C06 JL 2B17 ; less than zero? 1B0F:2B11 807EFD39 CMP BYTE PTR [BP-03],39 1B0F:2B15 7E05 JLE 2B1C ; between 0 & 9? 1B0F:2B17 B80100 MOV AX,0001 ; no, set flag=1 1B0F:2B1A EB02 JMP 2B1E ; keep flag 1B0F:2B1C 33C0 XOR AX,AX ; flag=0 1B0F:2B1E 0BC0 OR AX,AX ; is it zero? 1B0F:2B20 7507 JNZ 2B29 ; flag NO jumps away 1B0F:2B22 8A46FD MOV AL,[BP-03] ; Ok, get number 1B0F:2B25 8842CC MOV [BP+SI-34],AL ; Ok, store number 1B0F:2B28 46 INC SI ; inc storespace 1B0F:2B29 47 INC DI ; inc counter 1B0F:2B2A C45E06 LES BX,[BP+06] ; reset pointer 1B0F:2B2D 03DF ADD BX,DI ; point next number 1B0F:2B2F 26803F00 CMP BYTE PTR ES:[BX],00 ; input end? 1B0F:2B33 75CB JNZ 2B00 ; no:loop next num You now obviously understand that the "real" string is stored inside memory location [BP+SI-34]... set a memory breakpoint on this area to get the next block of code that fiddles with the transformed input. Notice how this routine "normalizes" the input, strips the "-" off and puts the 10 numbers together: user input: 1 2 1 2 1 2 1 2 1 2 End 1E7F:92E2 31 32 31 32 31 32 31 32 31 32 00 45 AF 1F 70 9B Stack ptr: 0 1 2 3 4 5 6 7 8 9 A B C D E F Let's now look at the "real" protection routine: the one that checks these numbers and throw you out if they are not "sound". Please pay attention to the following block of code: check_if_sum_other_9_numbers_=_remainder_of_the_third_number: :4B79 8CD0 MOV AX,SS ; we'll work inside the stack... :4B7B 90 NOP :4B7C 45 INC BP :4B7D 55 PUSH BP ; save real BP :4B7E 8BEC MOV BP,SP ; BP = stackpointer :4B80 1E PUSH DS ; save real Datasegment :4B81 8ED8 MOV DS,AX ; Datasegment = stacksegment :4B83 83EC04 SUB SP,+04 :4B86 C45E06 LES BX,[BP+06] ; BX points input_start :4B89 268A07 MOV AL,ES:[BX] ; load first number :4B8C 98 CBW ; care only for low :4B8D C45E06 LES BX,[BP+06] ; reset pointer :4B90 50 PUSH AX ; save 1st number :4B91 268A4701 MOV AL,ES:[BX+01] ; load 2nd number :4B95 98 CBW ; only low :4B96 8BD0 MOV DX,AX ; 2nd number in DX :4B98 58 POP AX ; get 1st number :4B99 03C2 ADD AX,DX ; sum with second :4B9B C45E06 LES BX,[BP+06] ; reset pointer :4B9E 50 PUSH AX ; save sum :4B9F 268A4707 MOV AL,ES:[BX+07] ; load 8th number :4BA3 98 CBW ; only low :4BA4 8BD0 MOV DX,AX ; 8th number in DX :4BA6 58 POP AX ; old sum is back :4BA7 03C2 ADD AX,DX ; sum 1+2+8 :4BA9 C45E06 LES BX,[BP+06] ; reset pointer :4BAC 50 PUSH AX ; save sum :4BAD 268A4703 MOV AL,ES:[BX+03] ; load 4rd number :4BB1 98 CBW ; only low :4BB2 8BD0 MOV DX,AX ; #4 in DX :4BB4 58 POP AX ; sum is back :4BB5 03C2 ADD AX,DX ; sum 1+2+8+4 :4BB7 C45E06 LES BX,[BP+06] ; reset pointer :4BBA 50 PUSH AX ; save sum :4BBB 268A4704 MOV AL,ES:[BX+04] ; load 5th number :4BBF 98 CBW ; only low :4BC0 8BD0 MOV DX,AX ; #5 in DX :4BC2 58 POP AX ; sum is back :4BC3 03C2 ADD AX,DX ; 1+2+8+4+5 :4BC5 C45E06 LES BX,[BP+06] ; reset pointer :4BC8 50 PUSH AX ; save sum :4BC9 268A4705 MOV AL,ES:[BX+05] ; load 6th number :4BCD 98 CBW ; only low :4BCE 8BD0 MOV DX,AX ; #6 in DX :4BD0 58 POP AX ; sum is back :4BD1 03C2 ADD AX,DX ; 1+2+8+4+5+6 :4BD3 C45E06 LES BX,[BP+06] ; reset pointer :4BD6 50 PUSH AX ; save sum :4BD7 268A4706 MOV AL,ES:[BX+06] ; load 7th number :4BDB 98 CBW ; only low :4BDC 8BD0 MOV DX,AX ; #7 in DX :4BDE 58 POP AX ; sum is back :4BDF 03C2 ADD AX,DX ; 1+2+8+4+5+6+7 :4BE1 C45E06 LES BX,[BP+06] ; reset pointer :4BE4 50 PUSH AX ; save sum :4BE5 268A4708 MOV AL,ES:[BX+08] ; load 9th number :4BE9 98 CBW ; only low :4BEA 8BD0 MOV DX,AX ; #9 in DX :4BEC 58 POP AX ; sum is back :4BED 03C2 ADD AX,DX ; 1+2+8+4+5+6+7+9 :4BEF C45E06 LES BX,[BP+06] ; reset pointer :4BF2 50 PUSH AX ; save sum :4BF3 268A4709 MOV AL,ES:[BX+09] ; load 10th # :4BF7 98 CBW ; only low :4BF8 8BD0 MOV DX,AX ; #10 in DX :4BFA 58 POP AX ; sum is back :4BFB 03C2 ADD AX,DX ; 1+2+8+4+5+6+7+9+10 :4BFD 0550FE ADD AX,FE50 ; clean sum to 0-51 :4C00 BB0A00 MOV BX,000A ; BX holds 10 :4C03 99 CWD ; only AL :4C04 F7FB IDIV BX ; remainder in DX :4C06 C45E06 LES BX,[BP+06] ; reset pointer :4C09 268A4702 MOV AL,ES:[BX+02] ; load now # 3 :4C0D 98 CBW ; only low :4C0E 05D0FF ADD AX,FFD0 ; clean # 3 to 0-9 :4C11 3BD0 CMP DX,AX ; remainder = pampered #3? :4C13 7407 JZ 4C1C ; yes, go on good guy :4C15 33D2 XOR DX,DX ; no! beggar off! Zero DX :4C17 33C0 XOR AX,AX ; and FLAG_AX = FALSE :4C19 E91701 JMP 4D33 ; go to EXIT let's_go_on_if_first_check_passed: :4C1C C45E06 LES BX,[BP+06] ; reset pointer :4C1F 268A4701 MOV AL,ES:[BX+01] ; now load #2 anew :4C23 98 CBW ; only low :4C24 05D7FF ADD AX,FFD7 ; pamper adding +3 :4C27 A38D5E MOV [5E8D],AX ; save SEC_+3 :4C2A 3D0900 CMP AX,0009 ; was it < 9? (no A-F) :4C2D 7E05 JLE 4C34 ; ok, no 0xletter :4C2F 832E8D5E0A SUB WORD PTR [5E8D],+0A ; 0-5 if A-F :4C34 C45E06 LES BX,[BP+06] ; reset pointer :4C37 268A07 MOV AL,ES:[BX] ; load 1st input number :4C3A 98 CBW ; only low :4C3B 05C9FF ADD AX,FFC9 ; pamper adding +7 :4C3E A38F5E MOV [5E8F],AX ; save it in FIR_+7 :4C41 0BC0 OR AX,AX ; if #1 > 7 :4C43 7D05 JGE 4C4A ; no need to add 0xA :4C45 83068F5E0A ADD WORD PTR [5E8F],+0A ; FIR_+7 + 0xA now_we_have_the_sliders_let's_prepare_for_loop: :4C4A C45E0E LES BX,[BP+0E] ; Set pointer to E :4C4D 26C747020000 MOV WORD PTR ES:[BX+02],0000 ; 0 flag :4C53 26C7070000 MOV WORD PTR ES:[BX],0000 ; 0 flag :4C58 C706975E0900 MOV WORD PTR [5E97],0009 ; counter=9 :4C5E E99500 JMP 4CF6 ; Jmp check_counter loop_8_times: :4C61 C45E06 LES BX,[BP+06] ; reset pointer :4C64 031E975E ADD BX,[5E97] ; add running counter :4C68 268A07 MOV AL,ES:[BX] ; load # counter+1 :4C6B 98 CBW ; only low :4C6C 50 PUSH AX ; save 10th number :4C6D A18D5E MOV AX,[5E8D] ; ld SEC_+3 down_slider :4C70 BA0A00 MOV DX,000A ; BX holds 0xA :4C73 F7EA IMUL DX ; SEC_+3 * 0xA :4C75 03068F5E ADD AX,[5E8F] ; plus FIR_+7 up_slider :4C79 BAA71E MOV DX,1EA7 ; fixed segment :4C7C 8BD8 MOV BX,AX ; BX = Lkup_val=(SEC_+3*10+FIR_+7) :4C7E 8EC2 MOV ES,DX ; ES = 1EA7 :4C80 268A870000 MOV AL,ES:[BX+0000] ; ld 1EA7:[Lkup_val] :4C85 98 CBW ; only low: KEY_PAR :4C86 8BD0 MOV DX,AX ; save KEY_PAR in DX :4C88 58 POP AX ; repops 10th number :4C89 03C2 ADD AX,DX ; RE_SULT=KEY_PAR+#10 :4C8B 05D0FF ADD AX,FFD0 ; polish RE_SULT :4C8E 99 CWD ; only low: RE_SULT :4C8F 8956FC MOV [BP-04],DX ; save here KEY_PAR [9548] :4C92 8946FA MOV [BP-06],AX ; save here RE_SULT [9546] :4C95 0BD2 OR DX,DX ; KEY_PAR < 0? :4C97 7C0F JL 4CA8 ; yes: KEY_PAR < 0 :4C99 7F05 JG 4CA0 ; no: KEY_PAR > 0 :4C9B 3D0900 CMP AX,0009 ; KEY_PAR = 0 :4C9E 7608 JBE 4CA8 ; no pampering if RE_SULT < 9 :4CA0 836EFA0A SUB WORD PTR [BP-06],+0A ; else pamper :4CA4 835EFC00 SBB WORD PTR [BP-04],+00 ; and SBB [9548] :4CA8 C45E0E LES BX,[BP+0E] ; reset pointer to E :4CAB 268B4F02 MOV CX,ES:[BX+02] ; charge CX [958C] :4CAF 268B1F MOV BX,ES:[BX] ; charge BX slider [958A] :4CB2 33D2 XOR DX,DX ; clear DX to zero :4CB4 B80A00 MOV AX,000A ; 10 in AX :4CB7 9A930D2720 CALL 2027:0D93 ; call following RO_routine This is the only routine called from our protection, inside the loop (therefore 8 times), disassembly from WCB. Examining this code please remember that we entered here with following configuration: DX=0, AX=0xA, CX=[958C] and BX=[958A]... 1.0D93 56 push si ; save si 1.0D94 96 xchg ax, si ; ax=si, si=0xA 1.0D95 92 xchg ax, dx ; dx=0xA ax=dx 1.0D96 85C0 test ax, ax ; TEST this zero 1.0D98 7402 je 0D9C ; zero only 1st time 1.0D9A F7E3 mul bx ; BX slider! 0/9/5E/3B2... 1.0D9C >E305 jcxz 0DA3 ; cx=0? don't multiply! 1.0D9E 91 xchg ax, cx ; cx !=0? cx = ax & ax = cx 1.0D9F F7E6 mul si ; ax*0xA in ax 1.0DA1 03C1 add ax, cx ; ax= ax*0xA+cx = M_ULT 1.0DA3 >96 xchg ax, si ; ax=0xA; si evtl. holds M_ULT 1.0DA4 F7E3 mul bx ; ax= bx*0xA 1.0DA6 03D6 add dx, si ; dx= dx_add 1.0DA8 5E pop si ; restore si 1.0DA9 CB retf ; back to caller with two parameters: DX and AX Back_to_main_protection_loop_from_RO_routine: :4CBC C45E0E LES BX,[BP+0E] ; reset pointer :4CBF 26895702 MOV ES:[BX+02],DX ; save R_DX par [958C] :4CC3 268907 MOV ES:[BX],AX ; save R_AX par [958A] :4CC6 0346FA ADD AX,[BP-06] ; add to AX RE_SULT [9546] :4CC9 1356FC ADC DX,[BP-04] ; add to DX KEY_PAR [9548] :4CCC C45E0E LES BX,[BP+0E] ; reset pointer :4CCF 26895702 MOV ES:[BX+02],DX ; save R_DX+KEY_PAR [958C] :4CD3 268907 MOV ES:[BX],AX ; save R_AX+RE_SULT [958A] :4CD6 FF0E8D5E DEC WORD PTR [5E8D] ; down_slide SEC_+3 :4CDA 7D05 JGE 4CE1 ; no need to add :4CDC 83068D5E0A ADD WORD PTR [5E8D],+0A ; pamper adding 10 :4CE1 FF068F5E INC WORD PTR [5E8F] ; up_slide FIR_+7 :4CE5 A18F5E MOV AX,[5E8F] ; save upslided FIR_+7 in AX :4CE8 3D0900 CMP AX,0009 ; is it over 9? :4CEB 7E05 JLE 4CF2 ; no, go on :4CED 832E8F5E0A SUB WORD PTR [5E8F],+0A ; yes, pamper -10 :4CF2 FF0E975E DEC WORD PTR [5E97] ; decrease loop counter check_loop_counter: :4CF6 833E975E03 CMP WORD PTR [5E97],+03 ; counter = 3? :4CFB 7C03 JL 4D00 ; finish if counter under 3 :4CFD E961FF JMP 4C61 ; not yet, loop_next_count loop_is_ended: :4D00 C45E06 LES BX,[BP+06] ; reset pointer to input :4D03 268A4701 MOV AL,ES:[BX+01] ; load 2nd number (2) :4D07 98 CBW ; only low :4D08 05D0FF ADD AX,FFD0 ; clean it :4D0B BA0A00 MOV DX,000A ; DX = 10 :4D0E F7EA IMUL DX ; AX = SEC_*10 = 14 :4D10 C45E06 LES BX,[BP+06] ; reset pointer :4D13 50 PUSH AX ; save SEC_*10 :4D14 268A07 MOV AL,ES:[BX] ; load 1st number (1) :4D17 98 CBW ; only low :4D18 8BD0 MOV DX,AX ; save in DX :4D1A 58 POP AX ; get SEC_*10 :4D1B 03C2 ADD AX,DX ; sum SEC_*10+1st number :4D1D 05D0FF ADD AX,FFD0 ; clean it :4D20 99 CWD ; only low :4D21 C45E0A LES BX,[BP+0A] ; get pointer to [9582] :4D24 26895702 MOV ES:[BX+02],DX ; save 1st (1) in [9584] :4D28 268907 MOV ES:[BX],AX ; save FINAL_SUM (15) [9582] :4D2B 33D2 XOR DX,DX ; DX = 0 :4D2D B80100 MOV AX,0001 ; FLAG TRUE ! :4D30 E9E6FE JMP 4C19 ; OK, you_are_a_nice_guy EXIT: :4D33 59 POP CX ; pop everything and :4D34 59 POP CX ; return with flag :4D35 1F POP DS ; AX=TRUE if RegNum OK :4D36 5D POP BP ; with 1st # in [9584] :4D37 4D DEC BP ; with FINAL_SUM in [9582] :4D38 CB RETF Let's translate the preceding code: first of all the pointers: At line :4B86 we have the first of a long list of stack ptrs: LES BX,[BP+06] This stack pointer points to the beginning of the input string, which, once polished from the "-", has now a length of 10 bytes, concluded by a 00 fence. At the beginning, before the main loop, 9 out of our 10 numbers are added, all but the third one. Notice that protection has jumped # 3 (and added # 8 out of the line). The rest is straightforward. Now, at line :4BFD we have our first "cleaning" instruction. You see: the numbers are hexadecimal represented by the codes 0x30 to 0x39. If you add FE50 to the minimum sum you can get adding 9 numbers (0x30*9 = 0x160) You get 0. The maximum you could have adding 9 numbers, on the contrary is (0x39*9=0x201), which, added to FE50 gives 0x51. So we'll have a "magic" number between 0x0 and 0x51 instead of a number between 0x160 and 0x201. Protection pampers this result, and retains only the last ciffer: 0-9. Then protection divides this number through 0xA, and what happens? DX get's the REMAINDER of it. If we sum the hexcodes of our (1212-1212-12) we get 0x1BE (we sum only 9 out of then numbers: the third "1" -i.e. "31"- does not comes into our count); 0x1BE, cleaned and pampered gives E. Therefore (0xE/0xA = 1) We get 1 with a remainder of 4. You may observe that of all possible answers, only sums finishing with A, B, C, D, E or F give 1 (and rem=0,1,2,3,4 or 5). Sums finishing 0 1 2 3 4 5 6 7 8 or 9 give 0 as result and themselves as reminder. The chance of getting a 0,1,2,3 or 4 are therefore bigger as the chance of getting a 5, 6, 7, 8 or 9. We are just observing... we do not know yet if this should play a role or not. Now this remainder is compared at :4C11 with the third number polished from 0x30-0x39 to 0-9. This is the only protection check for the registration number input: If your third number does not match with the remainder of the sum of all the 9 others numbers of your input you are immediately thrown out with FLAG AX=FALSE (i.e. zero). To crack the protection you now have to MODIFY your input string accordingly. Our new input string will from now on be "1242-1212- 12": we have changed our third number (originally a "2") to a "4" to get through this first strainer in the correct way. Only now protection starts its mathematical part (We do not know yet why it does it... in order to seed the random product number? To provide a check for the registration number you'll input at the end? We'll see). - Protection saves the second number of your input (cleaned with FFD7) in SEC_+3 [5E8D], pampering it if it is bigger than 9 (i.e. if it is 0xA-0xF). Here you'll have therefore following correspondence: 0=7 1=8 2=9 3=0 4=1 5=2 6=3 7=4 8=5 9=6. The second number of your input has got added +3. This is value SEC_+3. In (lengthy) C it would look like this: If (RegString(2)is lower than 7) RegString(2) = RegString(2)+3 Else Regstring(2) = ((RegString(2)-10)+3) - Protection saves your first number in FIR_+7 [5E8F] with a different cleaning parameter (FFC9). The next pampering adds 0xA if it was not 7/8/9 therefore you have here following correspondence 7=0 8=1 9=2 0=3 1=4 2=5 3=6 4=7 5=8 6=9). This is value FIR_+7. In (lengthy) C it would look like this: If (RegString(1) is lower than 3) RegString(1) = RegString(1)+7 Else Regstring(1) = ((RegString(1)-10)+7) So protection has "transformed" and stored in [5E8D] and [5E8F] the two numbers 1 and 2. In our RegString: 1242-1212-12 the first two numbers "12" are now stored as "94". These will be used as "slider" parameters inside the main loop, as you will see. Only now does protection begin its main loop, starting from the LAST number, because the counter has been set to 9 (i.e. the tenth number of RegString). The loop, as you'll see, handles only the numbers from 10 to 3: it's an 8-times loop that ends without handling the first and second number. What happens in this loop?... Well, quite a lot: Protection begins the loop loading the number (counter+1) from the RegString. Protection then loads the SEC_+3 down_slider parameter (which began its life as second number "transformed"), multiplies it with 0xA and then adds the up_slider parameter FIR_+7 (at the beginning it was the first number transformed). This sum is used as "lookup pointer" to find a parameter inside a table of parameters in memory, which are all numbers between 0 and 9. Let's call this value Lkup_val. Protection looks for data in 1EA7:[Lkup_val]. In our case (we entered 1242-1212-12, therefore the first SEC_+3 value is 9 and the first FIR_+7 value is 4): [Lkup_val] = 9*0xA+4; 0x5A+4 = 0x5E. At line :4C80 therefore AL would load the byte at 1EA7:005E (let's call it KEY_PAR), which now would be ADDED to the # counter+1 of this loop. In our case KEY_PAR at 1EA7:005E it's a "7" and is added to the pampered 0x32=2, giving 9. Let's establish first of all which KEY_PAR can possibly get fetched: the maximum is 0x63 and the minimum is 0x0. The possible KEY_PARs do therefore dwell in memory between 1EA7: and 1EA7:0063. Let's have a look at the relative table in memory, where these KEY_PARs are stored ("our" first 0x5Eth byte is underlined): 1EA7:0000 01 03 03 01 09 02 03 00-09 00 04 03 08 07 04 04 1EA7:0010 05 02 09 00 02 04 01 05-06 06 03 02 00 08 05 06 1EA7:0020 08 09 05 00 04 06 07 07-02 00 08 00 06 02 04 07 1EA7:0030 04 04 09 05 09 06 00 06-08 07 00 03 05 09 00 08 1EA7:0040 03 07 07 06 08 09 01 05-07 04 06 01 04 02 07 01 1EA7:0050 03 01 08 01 05 03 03 01-02 08 02 01 06 05 07 02 1EA7:0060 05 09 09 08 02 09 03 00-00 04 05 01 01 03 08 06 1EA7:0070 01 01 09 00 02 05 05 05-01 07 01 05 08 07 01 09 1EA7:0080 08 07 07 04 04 08 03 00-06 01 09 08 08 04 09 09 1EA7:0090 00 07 05 02 03 01 03 08-06 05 07 06 03 07 06 07 1EA7:00A0 04 02 02 05 02 04 06 02-06 09 09 01 05 02 03 04 1EA7:00B0 04 00 03 05 00 03 08 07-06 04 08 08 02 00 03 06 1EA7:00C0 09 00 00 06 09 04 07 02-00 01 01 01 01 00 01 FF 1EA7:00D0 00 FF FF FF FF 00 FF 01-00 00 00 00 00 00 00 00 An interesting table, where all the correspondences are between 0 and 9... are we getting some "secret" number here? But, hey, look there... funny, isn't it? Instead of only 0-0x63 bytes we have roughly the DOUBLE here: 0-0xC8 bytes (the 01 sequence starting at CA "feels" like a fence). We'll see later how important this is. At the moment you should only "perceive" that something must be going on with a table that's two time what she should be. As I said the result of KEY_PAR + input number is polished (with a FFDO) and pampered (subtracting, if necessary, 0xA). Therefore the result will be the (counter+1) input number + KEY_PAR (let's call it RE_SULT], in our case, (at the beginning of the loop) a 9. Now (DX=0 because of the CWD instruction) DX will be saved in [9548] and RE_SULT in [9546]. Now Protection prepares for the RO_routine: resets its pointer and charges CX and BX from [958C] and from [958A] respectively, charges AX with 0xA and sets DX to zero. The routine performs various operations on AX and DX and saves the results in the above mentioned locations [958A] and [958C]. Now KEY_PAR and RE_SULT are added respectively to the DX and AX value we got back from the RO_routine call, and saved once more in the last two locations: AX+RE_SULT in [958A] and DX+KEY_PAR in [958C] Now the value in SEC_+3 is diminished by 1 (if it was 9 it's now 8, if it was zero it will be pampered to 9). It's a "slider" parameter (in this case a down_slider), typically used in relatively complicated protections to give a "random" impression to the casual observer. The value in FIR_+7, on the contrary, is augmented by one, from 4 to 5... up_sliding also. Protection now handles the next number of your input for the loop. In our case this loop uses following protection configuration with our "sliding" parameters: Input # pamp_2nd pamp_1st Lookup value KEY_PAR # RE_SULT # 10 = 2, SEC_+3= 9, FIR_+7= 4, Lkup_val = 0x5E, KEY=7 +2 = 9 # 9 = 1, SEC_+3= 8, FIR_+7= 5, Lkup_val = 0x55, KEY=3 +1 = 4 # 8 = 2, SEC_+3= 7, FIR_+7= 6, Lkup_val = 0x4C, KEY=4 +2 = 6 # 7 = 1, SEC_+3= 6, FIR_+7= 7, Lkup_val = 0x43, KEY=7 +1 = 7 # 6 = 2, SEC_+3= 5, FIR_+7= 8, Lkup_val = 0x3A, KEY=0 +2 = 2 # 5 = 1, SEC_+3= 4, FIR_+7= 9, Lkup_val = 0x31, KEY=4 +1 = 5 # 4 = 2, SEC_+3= 3, FIR_+7= 0, Lkup_val = 0x1E, KEY=5 +2 = 7 # 3 = 4, SEC_+3= 2, FIR_+7= 1, Lkup_val = 0x15, KEY=2 +4 = 5 Notice how our "regular" input 21212124 has given an "irregular" 94672575. You may legitimately ask yourself what should all this mean: what are these RE_SULTs used for? Well they are used to slide another parameter: this one inside the called routine... this is what happens to AX and DX inside the routine, and the lines after the called routine: :4CBF 26895702 MOV ES:[BX+02],DX ; save R_DX par [958C] :4CC3 268907 MOV ES:[BX],AX ; save R_AX par [958A] :4CC6 0346FA ADD AX,[BP-06] ; add to AX RE_SULT [9546] :4CC9 1356FC ADC DX,[BP-04] ; add to DX KEY_PAR [9548] :4CCC C45E0E LES BX,[BP+0E] ; reset pointer to E :4CCF 26895702 MOV ES:[BX+02],DX ; save R_DX+KEY_PAR [958C] :4CD3 268907 MOV ES:[BX],AX ; save R_AX+RE_SULT [958A] :4CC6 :4CC9 :4CCF Odd_DX :4CD3 slider_sum RE_SULT [958A] [958C] [958C] [958A] 0 0 0 0 0 9 5A 0 0 9 4 3AC 0 0 5E 6 24F4 0 0 3B2 7 71CE 1 1 24FB 2 7220 4 E 71D0 5 7572 4 90 7225 7579 Now the loops ends, having handled the input numbers from tenth to third. Protection loads the second number and multiplies it by 10 (let's call this result SEC_*10), in our case 2*0xA=14. Protection loads the first number and adds it to the multiplication, in our case 1+0x14=0x15 (FINAL_SUM]. Now everything will be added to FFDO to "clean" it. Pointer will now be set to the end of the input number. DX, zeroed by CDW, will be saved as parameter in [9584] and the cleaned and pampered sum will be saved in [9582]. FLAG is set to true and this routine is finished! No parameter are passed and the only interesting thing is what actually happens in the locations [9582], [9584], [958A] and [958C], i.e.: FINAL_SUM, 0, slider_sum, odd_dx. In the next lesson we'll crack everything, but I'll give you already some hints here, in case you would like to go ahead on your own: we'll see how the scheme used for the third (the registration) number show analogies and differences with the scheme we have studied (and cracked) here for the first number. Our 3434-3434-3434-3434-34 input string for the registration number will be transformed in the magic string 141593384841547431, but this will not work because the "magic" 12th number: "1" will not correspond to the remainder calculated inside this check through the previous locations of the other checks. Here the things are more complicated because every little change in your input string transforms COMPLETELY the "magic" string... therefore in order to pass the strainer you'll have to change 3434-3434-3434-3434-34 in (for instance) 7434-3434-3434- 3434-96. The "magic" string 219702960974498056 that this registration input gives will go through the protection strainer. Only then we'll be able to step over and finally crack the whole protection... it's a pretty complicated one as I said. Now crack it pupils... you have three months time. From this crack depends your admission to the Uni, there will be no other admission text till summer 1997 (it's a hell of work to prepare this crap)... work well. Well, that's it for this lesson, reader. Not all lessons of my tutorial are on the Web. You 'll obtain the missing lessons IF AND ONLY IF you mail me back (via anon.penet.fi) some tricks of the trade I may not know but YOU've discovered. I'll probably know most of them already, but if they are really new you'll be given full credit, and even if they are not, should I judge that you "rediscovered" them with your work, or that you actually did good work on them, I'll send you the remaining lessons nevertheless. Your suggestions and critics on the whole crap I wrote are also welcomed. E-mail +ORC +ORC an526164@anon.penet.fi